Roxana ontology: a standard-based knowledge model for the formalisation of adaptive human-based processes in the manufacturing industry

Abstract

In most European member states, employees stay with a company for over ten years. During this time, people gain valuable experience and build up expertise that is lost to production companies when employees leave. Despite increasing digitalisation, there will still be processes, especially in individual production, that require experts. Ontologies are an established method for formalising knowledge. Standards are needed to ensure interoperability. However, not all reference models are based on the standardised basic formal ontology. To the best of our knowledge, there are also no references for modelling human-bound production steps. We have developed the freely accessible ROXANA ontology based on actual use cases from special-purpose machines. This ontology is based on the basic formal ontology and uses references from the common core ontologies and the industrial ontology foundry. The difficulty with expert-bound process steps in production is individuality and complexity. The design of special-purpose machines is individual, as are the machine-specific documents and the associated workflows. This paper presents the ontology, explains it using practical examples, and shows its implementation in a real software-based expert system.

KEYWORDS:

• Ontology
• Basic Formal Ontology (BFO)
• Common Core Ontologies (CCO)
• Industrial Ontology Foundry (IOF)
• commissioning in manufacturing
• human-bounded processes

1. Introduction

Eurostat's statistical data collected from 1995 to 2005 shows that the average length of employment with a single employer extends to ten years or more. Despite country-specific variations among member states and additional un-disclosed influencing factors not mentioned here, it is apparent that employees tend to remain with a company for several years, thereby acquiring valuable experiential knowledge during their tenure (European Commission 2006). Many manual activities still determine manufacturing processes at small and medium-sized enterprises, particularly for companies with custom manufacturing operations. The company’s success largely depends on the domain experts’ skills and knowledge. Expertise is the most valuable resource in an increasingly knowledge-driven society. Retaining knowledge in companies is a decisive factor for competitiveness. New knowledge can be derived from the collective, and new employees can also benefit from the experience of other colleagues.

Ontologies are used for knowledge modelling in various areas, such as decision support (Jarrar et al. 2023). As part of a decision-based support system, ontologies secure knowledge (Rožanec et al. 2023). Research also considers ontologies combinatorially, such as cognitive digital twins. The benefits of ontologies include improving data search, knowledge extraction and interoperability (Psarommatis and May 2023; Zheng, Lu, and Kiritsis 2022). While OPC UA is often used as a standard for information modelling for factory automation, RDF-based knowledge graphs are better suited for representing expert knowledge with complex relationships between data elements. Although there are standards or references in ontology modelling, application-specific isolated solutions exist which do not use the existing knowledge formalised in the models (Ameri et al. 2022). Furthermore, domain-specific references or practical application ontologies are only sometimes public.

We developed ROXANA, a Reference Ontology for eXpert-bound processes in mANufActuring. In the primary role, Roxana functions as a template for modelling human-related activities in production, the representation of physical production entities, and the relationships between time-dependent physical state forms and process execution. These are processes where automation is impossible or economically viable due to their individuality or difficulty. The knowledge and expertise of the workers are lost to the company if these employees leave due to change, illness, or retirement. However, these employees’ high level of expertise also makes it difficult to formalise their work in a structured manner. A level of granularity that a trained but inexperienced colleague can understand is required. Although these processes have a high degree of individuality, the employees only carry out various basic activities. In its original form, the ontology uses the Basic Formal Ontology (BFO) and several Common Core Ontologies (CCO). We specified the taxonomy structures to strengthen the focus on the application domain. Part of this paper is also a 2nd version, where we mapped the concepts of the IOF Core. Users can choose the ROXANA version that is suitable for their application-specific circumstances.

The ROXANA ontology results from a research project describing the commissioning process at special-purpose machine manufacturers. Due to the individuality of the machine tools, it is a process that is exclusively performed manually by experienced and trained employees. There are usually only a few commissioning engineers. These experts use their experience to commission a machine or solve any problems. It must also be added that errors in previous processes, such as design or purchasing, often only come to light during commissioning. The following explanations of the ROXANA ontology contain a general description of the concepts. At the same time, there are examples from the commissioning process.

Section 2 briefly describes expert-based process steps and the application example from the research project. Part of this description is also our vision of knowledge. In the following section, we introduce a brief theory of ontologies, its model elements, and the notation used in the work. After explaining the selection of studies in section 4, we go into existing ontologies in production and briefly describe existing standards and references. We explain the development of ROXANA in detail in section 5. Using a practical example, we answer the competency questions posed at the beginning of the previous section with SPARQL queries in section 6. We conclude our consideration of the model in section 7 by implementing it in a software application. Finally, we summarise the work and the results in section 8 before highlighting further research aspects in section 9 and concluding from a management perspective in section 10.

2. Description of expert-bound processes and the use-case scenario

2.1. What is our vision of knowledge?

We believe ‘knowledge’ is not always understood with sufficient precision. There is a difference between knowledge, information, ability, and action. In this context, we would like to discuss why people play an essential role in production. After all, their expertise and skills are valuable corporate capital and are necessary to ensure the competitiveness of production companies. We will first briefly explain the emergence and development of knowledge using North’s knowledge ladder before moving on to the role of knowledge-bearing individuals.

Today’s society is characterised by digitalisation, among other things, and cognitive and networked systems. The concept of knowledge has also changed over the past centuries (North and Kumta 2014; North, Maier, and Haas 2018). North et al. state that we live in a ‘knowledge society 4.0’, where value creation occurs by utilising data, information, and knowledge. Symbols and data are the starting point. Information exists by adding meaning to this level. People process this information individually and combine it with empirical values to create knowledge in their reference system. Using this knowledge in action represents the next stage and reaches the level of competence when the knowledge can be adequately mobilised according to the situation. The knowledge ladder in Figure 1 illustrates the stages and how companies can pursue knowledge-orientated value creation. There are three highlighted areas in colour. The first area is knowledge generation. Knowledge as a ‘raw material’ represents the middle area. The upper level shows how competitiveness can be achieved through the targeted use of knowledge. (North and Kumta 2014; North, Maier, and Haas 2018)

Figure 1. Knowledge ladder according to North.

Seven stages in the following ascending order: ‘Character’, ‘Data’, ‘Information’, ‘Knowledge’, ‘Act’, ‘Expertise’ and ‘Competitiveness’. An arrow indicates the differentiation between explicit and implicit knowledge for the levels under ‘Act’ and ‘Knowledge’ respectively. Figure Long Description: Seven levels are divided by colour into three areas, in ascending order: area one consists of ‘Character’, ‘Data’, and ‘Information’, area two consists of ‘Knowledge’ and ‘Act’, and area three consists of ‘Expertise’ and ‘Competitiveness’. An arrow indicates the differentiation between explicit and implicit knowledge for the levels under ‘Act’ and ‘Knowledge’ respectively.

People with competencies are unique in their ability to draw analogous conclusions in novel situations. In an increasingly digitalised and automated world, people are taking on the ‘knowledge worker’ role. It describes the ability to be creatively active in a task. In contrast to machine applications, humans can further develop knowledge and respond adaptively to ad hoc challenges (Lake et al. 2017). Many incurred costs in the production process exist due to the knowledge factor (Stehr 2011).

2.2. A research project served as the basis

This knowledge also played a central role in a research project. The subject of the study was the commissioning of special-purpose machines from machine tool manufacturers to develop a digital expert system to provide support.

Commissioning is the final step in the manufacturing process and includes all activities in putting the product or module into an operational and intended state (European Parliament, Council of the European Union 2006). Commissioning is usually followed by the handover (also legal) to the customer. It is a complex process in which the work and possible design, procurement and assembly errors come to light. The costs of any corrections increase as the project progresses. The aim of the project was to develop a methodology for standardising, automating, and archiving socio-technical processes in an industrial environment.

The commissioning process is an expert-bound process due to the constantly individualised systems. Implementation requires the know-how and expertise of the commissioning engineers. They have extensive experience from past projects with partially or fully recurring activities. Nevertheless, there is a high proportion of individual activities or machine-specific settings. Existing (often exclusively analogue) data and information are also not used or insufficiently used by SMEs in practice. The complexity and individuality of commissioning prevent the standardisation of the process.

In the project, we first structured the commissioning process. Second, we conducted extensive expert interviews with the domain experts. We accompanied the processes as well and held workshops. The culmination of a profound collaboration between domain and ontology experts yielded an ontology, meticulously crafted, and subsequently integrated as a model within a software application. Subsequently, the software prototype was then tested in the industrial companies involved in the research project to validate its practical applicability.

3. Brief theoretical summary of ontologies, model elements, and notation

The term ontology originally came from philosophy, describing the investigation and categorisation of existence, reality, and possibility. Ontologies divide things that exist or are possible in the world into categories and deal with the laws that govern these categories (Grossmann 2020).

The field of artificial intelligence has adopted the term ontology for knowledge representation, the formal modelling of knowledge in computers. In this context, ontology continues to describe the model-like representation of the world (conceptualisation) and the actual result of this process as an explicit specification (Gruber 1993; 1995).

In principle, an ontology represents a catalogue of the types of things that exist in a particular domain and thus represents, among other things, properties, word meanings, and concept and relation types of a language, which are used to discuss a domain (Sowa 2000).

The use cases for ontologies are manifold. The terms and term hierarchies defined therein can be used, e.g., to classify documents, events, and other things. One example is the International Classification of Diseases (ICD) 4 developed by the WHO, which is used for statistics about diseases and causes of death.

Ontologies can be created using different means. Nevertheless, all approaches to the specification of ontologies generally have a common basis (Uschold and Gruninger 2004):

• a vocabulary with terms for the things in a domain

• a specification of the meaning of these terms, ideally described by some logic.

In the context of this work, we use the term ontology to describe things in a given subject area (e.g. vehicle, car, tyre in an automotive setting). These things are represented in the ontology as classes and are organised as a taxonomy. Each class has properties that describe its attributes and relationships to other classes including the restrictions that hold for the usage of these properties. (Uschold and Gruninger 2004)

Even if the specification of the terms should be as explicit as possible, the degree of formalisation of ontologies is variable (Guarino, Oberle, and Staab 2009; Uschold and Gruninger 2004). Informal ontologies, e.g., only define terms that are used in a particular environment or specific area. The meaning of the terms is often only stored as a textual description. Formalisation increases when terms are linked with more generic or specific terms, synonyms, or further relations to other terms in a so-called thesaurus. Languages such as XML Schema or the Unified modelling language (UML) for describing data models use extended language additional relationships beyond thesauri's limited expressiveness. More formalisation can be achieved by using logical language to describe terms and their relationships.

For the definition of ontologies in the context of the Semantic Web, mainly the data modelling language RDF Schema (RDFS) and the logical language Web Ontology Language (OWL), which is based on the principles of description logic (Baader 2009; 2010), are used (Baader, Horrocks, and Sattler 2005; Guarino, Oberle, and Staab 2009; Horrocks, Patel-Schneider, and van Harmelen 2003).

RDFS (Brickley and Guha 2014) allows the description of class hierarchies, the declaration of hierarchically structured properties with corresponding definition and value ranges as well as the definition of new data types for literals. OWL (Hitzler et al. 2012), as an ontology language, goes beyond the capabilities of RDFS. It also supports the set-oriented interpretation of classes (intersections, unions, complements, equivalence, exclusive disjunction) and local (class-related) fine-grained definitions for value ranges of properties (Horrocks, Patel-Schneider, and van Harmelen 2003).

Our work within this paper is based on OWL as an ontology language. Although it is possible to describe OWL ontologies in several textual syntaxes, we have chosen to use a graphical notation to simplify the presentation of our defined terms and their mutual relationships as well as their interaction with terms from existing ontologies. Figure 2 depicts our notation for classes and instances of ontologies.

Figure 2. Notation for classes and instances used in the scope of this paper.

Read the detailed description of this figure

Rectangles symbolise classes and instances, and arrows symbolise relationships, such as subclasses or object relations. Specifications of entities from other ontologies are marked in colour by blocks that build on each other. Figure Long Description: Rectangles symbolise classes and instances, and arrows symbolise relationships, such as subclasses or object relations. The illustration is general in the upper part and uses the example of a car in the lower part. Accordingly, a car represents a subclass of vehicle. The object relation ‘has Component’ shows that tyres are components of a car. Specifications of entities from other ontologies are marked in colour by blocks that build on each other. From the general to the specific, the BFO is characterised by the IOF Core and the latter, in turn, by the ROXANA ontology.

The left side shows classes with their superclass and subclass relationships expressed by ‘rdfs:subClassOf’ and applicable object properties that relate one class instance to one or more other instances. The right side depicts a compact notation for instances using three coloured stacked boxes above a particular instance to describe the transitive subclass relationships across the ROXANA, IOF Core and BFO ontologies. Respective examples for each notation are given in the lower part of the figure.

4. Related work

4.1. Study selection

Ontologies originated in medicine but are now a well-known method for formalising and securing knowledge in production. In 2016, the Industrial Ontology Foundry (IOF) was founded to create a model reference for the industry. For the study search, we used the Scopus database, which claims to contain the largest number of peer-reviewed specialist literature (Elsevier 2023). We applied two general requirements. Firstly, the study must be English-language and, therefore, an international publication; secondly, it must be in the final publication phase. We did not differentiate between accessibility in the sense of open-access publication. We use the following search terms for title, abstract and keyword research:

• Production application domain: ‘production OR manufacturing’

• Knowledge model ontology: ‘ontology’

• Modelling reference: ‘bfo OR basic formal ontology’

After analysing the abstracts, we recognised a fundamental distinction between ontologies in application and the presentation of newly developed knowledge models. The modelling of production-related topics, such as processes or machine components, was the subject of the following studies: Psarommatis et al. (Psarommatis, Fraile, and Ameri 2023) with ‘Zero Defect Manufacturing’ (ZDM for short), Dimassi et al. (Dimassi et al. 2021) with ‘mecHanical objEcts of 4D pRintingand programmable Matter for nExt-generation of CAD systemS’ (HERMES for short), Sarkar et al. (Sarkar and Šormaz 2019a) with the ‘Product Design Ontology’, Sarkar et al. (Sarkar and Šormaz 2019b) with an ontology for the representation of machine tool capabilities and Orqellana et al. (Orellana and Mandrick 2019) with the ‘Systems Engineering reference ontology’.

After removing the BFO limitation, we found 449 matches in ‘engineering’ and ‘computer science’. Figure 3 shows the annual number of publications. We observe a clear trend from 2004 onwards, and regardless of whether the focus was on the use of ontologies or the presentation of ontological concepts, we can clearly state that there was an increase in development efforts.

Figure 3. Annual number of Scopus-listed studies on ontologies in production with a focus on engineering and computer science, survey date mid-2023.

A diagram showing the years 1994 to 2022 on the X-axis and the number of studies limited to 70 on the Y-axis reveals that the number of publications increased from 2004 onwards, while there were almost no publications in the years before.

In addition to the Scopus results, we would also like to mention the ‘Landscape of Ontology Standards’ paper by Sarkar et al. (Sarkar et al. 2023). This document reports domain-specific ontologies published by standardisation bodies such as ISO, IEC and ETSI. The aim is to strengthen the reuse of existing ontologies instead of developing an ‘isolated solution’. By presenting the current state of research, we would like to introduce common modelling aspects of production. We therefore present mainly practical ontologies as listed in the ‘Landscape of Ontology Standards’.

4.2. Ontologies in manufacturing

While ontologies have their origin mainly in knowledge modelling in the biomedical field, they are also increasingly finding their way into manufacturing. Although these ontologies may be classified according to multiple criteria, they mainly differ regarding the covered life-cycle stages of a production system: engineering, commissioning, operation, technical service, modernisation, and decommissioning (Kristian et al. 2010). The following does not claim to be exhaustive but gives an overview of relevant ontologies from the field of manufacturing.

Ontologies like OntoCAPE (Morbach, Yang, and Marquardt 2007; Morbach, Wiesner, and Marquardt 2009) and MASON (Lemaignan et al. 2006) target the engineering phase of a production system and support process planning by formalising products, processes, and manufacturing operations along with required resources, tools, and personnel. OntoCAPE focusses on chemical process systems, while MASON describes discrete manufacturing processes.

The Additive Manufacturing Ontology (AMO) (Mohd Ali et al. 2019) extends the scope of ontologies like MASON to the whole product life cycle. The representation is based on main concepts: process, material, and information. The ontology is designed as a mid-level ontology and intends to assist in developing new products by providing knowledge artefacts for the related manufacturing domains. AMO tries to improve reuse by basing its concepts on prior work from the BFO and CCO.

In addition to ontologies centred around the design of manufacturing processes, there are also ontologies like the Functionally Graded Materials Ontology (FGMO) (Mohd Ali et al. 2021) that has a strong focus on the product itself and its material characteristics.

The Manufacturing Service Description Language (MSDL) (Ameri and Dutta 2006) and the Manufacturing service Ontology (MaRCo) (Järvenpää et al. 2019) focus on describing capabilities to allow automatic matchmaking between product requirements and capabilities of production processes and systems. MaRCo extends the approach of MSDL by allowing the fine-grained definition of basic capabilities like ‘moving’ and ‘releasing’ that can be combined into more complex ones like ‘picking’, ‘transporting’ and ‘placing’.

The Innovative Capabilities of Additive Manufacturing (ICAM) ontology reuses parts of MSDL and supports the modelling of product features and the related additive manufacturing processes (Hagedorn, Krishnamurty, and Grosse 2018).

The operating phase with scheduling and execution of production orders is supported by the ADACOR architecture (Borgo and Leitão 2004, 2007). The ADACOR ontology focusses on describing the relationships between product types, orders, and available production resources by using only 16 classes with a flat hierarchy. Another example is the ontology integrating process and quality control (GRACE) (Castellini et al. 2011; Leitao et al. 2012). It describes manufacturing processes along with the related quality control tasks and evaluates them for the use case of washing machine production.

The technical service of manufacturing systems is covered by the Reference Ontology for the Maintenance domain (ROMAIN) (Karray et al. 2019). It represents comprehensive concepts of maintenance management, e.g., the maintenance strategy and associated workflows with individual maintenance steps. With the original intention to serve as a reference ontology, it is also considered today in IOF development efforts.

4.3. Ontology standards and references

This section gives a brief overview of relevant ontologies developed for knowledge representation in several domains, especially for the description of industrial entities. For the creation of ROXANA we have carefully reviewed existing base ontologies before we first selected the CCO and in our latest version the IOF Core as a base layer to ensure the interoperability of our definitions.

4.3.1. Suggested Upper Merged Ontology: SUMO

SUMO (Niles and Pease 2001) was developed in the late 1990s and early 2000s and is a large, comprehensive ontology that provides a foundational framework for representing general knowledge and concepts in a wide range of domains.

4.3.2. Descriptive Ontology for Linguistic and Cognitive Engineering: DOLCE

DOLCE (Borgo et al. 2022) is rooted in philosophy, particularly the phenomenological tradition. It emphasises a careful analysis of the nature of entities, qualities, and relationships. The ontology seeks to capture the structure of reality based on philosophical insights.

4.3.3. Basic Formal Ontology: BFO

BFO (Otte, Beverley, and Ruttenberg 2022) adopts a top-level, foundational approach to ontology design, aiming to capture universal categories and relationships. This ontology is widely applied in various domains, including biology and medicine, offering a robust framework for interoperability and data integration (Arp, Smith, and Spear 2015). Its hierarchical structure ensures broad compatibility across diverse applications.

4.3.4. Common Core Ontologies: CCO

CCO (Rudnicki 2019) comprise twelve ontologies that are designed to represent and integrate taxonomies of generic classes and relations across all domains of interest. They are a mid-level extension of BFO where every class in CCO is asserted to be a subclass of some class in BFO, and the generic relations defined in BFO (e.g. ‘has_part’) are adopted. Accordingly, CCO classes and relations are heavily constrained by the BFO framework, from which it inherits much of its basic semantic relationships.

4.3.5. IOF Core

Like CCO ontologies the IOF Core (Kulvatunyou et al. 2018) is an extension of BFO (Smith et al. 2019). In contrast to CCO, which addresses multiple domains, the IOF Core focus on the industrial domain with its specific classes and relationships. By aligning the terms with upper-level concepts from BFO the preservation of common semantics is achieved while providing a richer vocabulary for describing industrial entities than CCO.

4.4. Ontological model content from production compared with the BFO standard

If ontologies utilise different basic concepts, the ontological concepts are not directly comparable. Nevertheless, to provide an overview of which aspects of production the models represent, we have determined the BFO counterparts to the ontology-specific concepts. Figure 4 shows the 12 ontologies with a marker if the model considers the corresponding concepts. The (production-relevant) concepts can be found under continuant and occurrent by the structure of the BFO. Variable, material, event, and state represent additions. The taxonomy of the ‘time-independent’ observation variables is more extensive than that of the ‘time-dependent’ occurrent due to the subdivision into generically and specifically dependent continuant and independent continuant. Users can use the first section to describe information about an entity. There is a general dependency on other concepts, e.g., the reference to a physical object. For example, local referencing can be created on an object like the workpiece surface.

Figure 4. 12 ontologies from the production domain and the comparison of the model contents according to the BFO elements.

Dots indicate which concepts are contained in the 12 ontologies as counterparts to the elements in the BFO. In total, 12 entities of the BFO are represented.

In contrast, independent continuants are independent according to their designation, so the modelling of these represent entities. This includes all physically real things, such as the machine components, the materials used for processing, or the people involved in production. The third form includes roles that machines or people can assume, such as the role of the commissioning engineer, the electrician, or the processing functions of a system. Occurrent divides into event, state, and process in Figure 4. The former describes a change that occurs over time, the latter describes a state that lasts for a certain period, and the latter often describes a process consisting of several operations.

The overview shows a strong representation in the upper range, especially of independent and generically dependent continuants. Artifact is a component of all the ontologies analysed. Information entities, materials, persons, and function descriptions are almost wholly model content. In contrast, spatial information or role distinctions are of secondary importance. We also want to point out that geographical information is product-related, i.e., it does not refer to the location of the production site. We note that variable values or quality variables are contained in almost every second ontology. In some ontologies, the modelling of the former is not represented via concepts but via datatype relations, see MSDL, among others, or is done indirectly and via individual entities, such as ‘ItemSize’ or ‘ShapeAndSizeInformation’ in MARCO. The markings of the GRACE ontology in the third section characterise a partial representation. For example, no separate entities exist. Instead, the meaning is directly associated with physical objects as ‘characteristics’ (Leitao et al. 2012). There is a uniqueness in the modelling of ‘Process’ in time-bound concepts. This shows that processes play an important role but are rarely differentiated in duration for event and state.

5. The reference ontology ROXANA

5.1. Overarching purpose

The ROXANA ontology functions as a specialised modelling concept tailored for expert-based commissioning, facilitating the instantiation of ontology with internal company process documents. Within the scope of our research project, we developed a natural language processing pipeline and subsequently crafted a mapper based on it. This mapper categorises semi-structured and non-numeric text data, subsequently serialising it as RDF within the ROXANA model (albeit not extensively discussed within this paper). The instantiated knowledge model was embedded into a software application, constituting an expert system designed to aid professionals in commissioning (Section 7).

The centre of Figure 5 illustrates the hierarchical levels in terms of interoperable ontology modelling. The BFO serves as the top-level ontology, while in version one, selected CCOs were employed as mid-level ontologies. In version two, model elements were mapped onto the IOF Core as domain mid-level ontology.

Figure 5. Abstract relationship between knowledge model and data instantiation for integration and use in a software application.

A pyramid is made up of the BFO as the top-level ontology, the CCOs and IOF Core as the mid-level ontology in the middle, and ROXANA as the domain application ontology at the lowest level. A software application uses the RDF-serialised data based on ROXANA, which is displayed at the same level of the ontology.

ROXANA builds upon the upper taxonomic structures and further specifies them, as elaborated in subsequent sections. The instantiated ROXANA model, beyond its application in the software, can serve as a modelling foundation for other domain considerations involving human-related activities in production. The use of ontologies in the project facilitated knowledge transfer and growth, particularly in utilising intelligent search/suggestion and reuse functionalities. Leveraging the knowledge model embedded within our software prototype, commissioning engineers could digitally compile comprehensive process execution chains, execute them with guided assistance, and meticulously document processes and errors.

5.2. Competency question

According to Grueninger and Fox, competence questions (CQ) characterise concepts and set goals for developing new ontologies (Grüninger and Fox 1995). What should the knowledge modelling represent?

In practice, it has become established in ontology development to pose so-called CQ at the beginning. These are questions that can be answered with the help of the model. The ontology represents a section of reality. These competency questions, therefore, represent the requirements of the ontological model and thus contribute to needs-based development. ROXANA provides a vocabulary to describe:

• CQ.1 Error analysis: Which precedence relationship applies to which machine-specific faults?Errors occur with a process. Even if workers do not always consciously cause errors, they do initiate the human-bound processes. Consequently, it is possible to determine the precedence relationship of errors through the precedence relationship of processes. In production itself, those relationships can provide information about cause and effect.

• CQ.2 Order of steps and states of technical components: Which process steps lead to a change in the state of components, and which state forms must be present for this to occur? Part of commissioning involves the functional and safety-related inspection of the machine. The status forms of components, therefore, play an essential role.

• CQ.3 State as a process requirement: In which process were the prerequisites created for the component states? A deviation in the process sequence is possible for various reasons. For example, missing or delayed orders can justify the early execution of downstream processes. A system may have interlinked relationships between status forms. Consequently, it may be necessary to check whether the prerequisites for a current process step from a previous one exist.

Experts can often answer these questions, but it becomes more difficult with extensive process steps. It can also be a challenge to encompass the entirety of the interlinked interactions in a machine. Commissioning involves many process steps, which require things and produce outputs. In contrast to table-based databases, the advantage of ontologies is that users can query entire information chains without knowing the number of intermediate elements.

5.3. Purpose and basic structure

Like every ontology, ROXANA also has a thematic focus. This is on the modelling of expert-related activities in the production environment. The model can represent the following areas:

• modelling of human-related processes in production by categorising human activities,

• modelling of process and work instructions, including subplans,

• modelling of interrelationships between machine variables and parameterisation processes,

• modelling of machine components and their state characteristics over time,

• modelling of workers and their affiliation to a specialist area, as well as their level of experience.

As part of the research project, we developed the ROXANA model, as shown in Figure 6. The project partners are unique machine manufacturers. The subject of the analysis was the commissioning of these machines. Due to the individuality of the systems, the process took place exclusively manually. Therefore, the analysis focusses on the human-related production steps.

Figure 6. Overview of the central concept elements of the ROXANA ontology; version one using the BFO standard and the CCO references.

Exemplary entities show the relationships in ROXANA. Partially overlapping borders indicate different modelling aspects, such as ‘Relation to Machine Variables’ or ‘Machine Components and States’.

The example shows a precedence relationship between two processes: the class ‘ActOfCommissiongOpen’ and ‘ActOfCommissiongSet’. The prefix ‘rox’ and the colour coding show the developments within ROXANA. The model elements utilise existing CCO structures in its first version. A dashed arrow points from ‘rox:ActOfCommissiong’ to indicate that it is a subclass of ‘cco:ActOfArtifactAssembly‘. The model contains concepts for representing technical machine components. We added several concrete designations, such as ‘clamp’, ‘contactor’, or ‘switch’ as specific electrical components. We used the research project to define those material units. Even though we have already been able to recognise and model many differentiations, we do not claim completeness. In this regard, the granularity at which users would like to model technical components arises. There could be further specifications based on the ROXANA elements.

Concerning the modelling aspect of categorising activities, Figure 7 illustrates the assignment to the BFO and CCO taxonomy. We defined the ‘ActOfCommissiong’ class as a subclass of ‘ActArtifactAssembly’. According to the CCO definition, this assignment involves processes in which a new ‘Artifact’ is created by assembling parts. Commissioning also includes mechanical and electrical assembly. It also includes the steps involved in testing a machine, particularly concerning safety-related aspects. This includes, e.g., ensuring that the machine starts only if the safety doors are closed and locked. Users of the ontology can now make instantiations according to this class taxonomy. If an activity does not yet exist, a class must be added analogue to the naming convention. All classes are independent of each other.

Figure 7. Categorisation of human activities in commissioning as subclasses of ‘ActOfCommissiong’; version one, based on the BFO and CCO taxonomy.

An excerpt from the ontology editor Protegé shows the class taxonomy under ‘occurent’ with the categorisation of human activities as subclasses under ‘Act of Artifact Assembly’.

Based on monitoring the commissioning process in practice and analysing the process instructions, we identified 23 basic activities. These activities are access, attach, check, close, compare, connect, control, disconnect, enter, fill, lock, measure, move, open, push, remove, set, start, turn off, turn on, unlock, upload, and wait. We define a basic activity as a single action, like opening, measuring, or filling. For example, if a worker opens the door, they must first unlock it (‘rox:ActOfCommissioningUnlock’) before opening it (‘rox:ActOfCommissioningOpen’).

One challenge in the modelling was defining the granularity in categorising human-related activities. There were three production companies in the research project. The reduction of steps would have been possible for individual companies. The commissioning engineers were experienced employees. They inevitably have a different understanding than non-experts. The question was to what extent it is possible to combine steps and thus achieve a reduction in the modelling. However, what can be summarised for one company may need to be clarified for another. Our objective was to develop a concept with which it is possible to model the individual commissioning process in different companies. So, it would have been theoretically conceivable to concretise the opening process by pressing the door handle and the pendulum movement of the door. However, this form of granularity was different from the purpose of the modelling. Instead, it was crucial to determine whether a human agent can understand a single action activity. Thus, it can be assumed that everyone knows what to do with filling or unlocking as one action.

Some companies had semi-structured process instructions. Commissioning is a complex process and consists of several sub-components. For example, the process usually starts with general preparatory work, such as checking the electrical connections or all circuit breakers. The sum of all this work could be part of a subplan. Another subsequent subplan is the commissioning of the control system. Although the machines differ fundamentally between the system manufacturers, the activities are similar initially.

In ROXANA we define ‘rox:Plan’ and ‘rox:SubPlan’. The distinction is also apparent in the stored definition: ‘A general plan is a plan that prescribes a series of intentional actions and usually consists of several subplans’ whereas ‘A subplan is a plan that prescribes some set of Intentional Acts and forms an overall plan with other subplans’.

In industry, whether in production or logistics, variables, e.g., machine values, process parameters or other characteristics, play an essential role. A few selected variables were important in the commissioning application. Specifically, these variables were the angle, the current, the pressure, the number of revolutions, the rotational speed, the temperature, and the time. A concrete example is the setting of the rotary table to a 45-degree angle. This scenario requires modelling the primary activity ‘Setting the angle of the turntable’ and the degree angle, as well as the connecting relation ‘has value’. We have added the class of variables and the object relation ‘has_value’ to the model concept in version one of ROXANA. We have assigned the subclass to ‘cco:quality’. According to the annotation, it is a ‘specifically dependent continuant’ which, except for ‘role’ and ‘disposition’, does not require a process to exist. Listed examples are length, temperature, or mass. The subordination, therefore, seemed appropriate. We want to point out that other ontological works distinguish further, e.g., between ‘programme parameter’, ‘quantity value’ and ‘variable’. For more details on the definitions and examples, please refer to the Open Energy Ontology (Repository for the Open Energy Ontology 2023). According to the information, the commissioning process variables correspond to ‘quantity value’. The definition states that it is a value with a unit used to quantify an entity. Especially in production, there are variety of variables. The ones included in the first version represent a subset. Nevertheless, the application-specific reduction by other variables is possible without further ado. Users of the ontology can add individual process values in the same way. This way, we will gradually supplement the ontology for other production companies. In version one of ROXANA, we use the CCO Measurement Ontology to specify units for the variables. In Figure 6, the reuse of these concepts is indicated by ‘cco:uses_measurement_unit’.

If we now consider the purpose of manual activities in production, the goal is usually based on producing a good. These are material, non-living entities in a broader sense. The included CCO Artifact contains specifications of the BFO concept ‘Object’. The Artifact Ontology specifies possible material units for a more comprehensive area than production, such as the military sector. Nevertheless, the ontology does not include differentiated concepts like an initiator or a clamp.

For this reason, ROXANA adds specific physical entities as they exist in production. In concrete terms, these are the machine’s components in the research project. However, any generic material entities will likely be installed in other production facilities. At the same time, users can similarly supplement other physical entities. Depending on the production domain, the physical entities can also vary. In ROXANA 2, we have mapped the structures of the IOF Core and subordinated these class additions to the ‘Piece of Equipment’ concept, see Figure 8.

Figure 8. Specification of the IOF Core class taxonomy around material machine components; on the right the subclasses under ‘PieceOfEquipment’ in ROXANA and on the left the original IOF Core differentiation.

Two excerpts from the ontology editor Protegé show the class taxonomy, on the right-hand side under ‘Piece of Equipment’ in ROXANA and on the left-hand side the subclasses in the IOF Core under ‘material entity’.

During commissioning, the states of machine components are an essential part of the process. Initially, modelling an artifact via ‘participates in’ seemed suitable. However, after closer analysis, we concluded that the time-dependent appearance of a physical object is more important than the matter itself. Instead of modelling a relation between an artifact and a process (e.g., via ‘participates in’), participation occurs via a specific state, as shown in Figure 6. The material entity can take on different state forms. For example, as a physical sub-component of a machine, the security door can be closed, bolted, and opened. The Event CCO defines ‘stasis’ as: ‘A Process in which one or more Independent Continuants endure in an unchanging condition’. Such a condition can occur according to the functional determination of a component. Likewise, a particular state may be forced to be able to carry out a process. In this case, it is usually not a functional state. The clamp, e.g., is a physical unit that makes it possible to establish a detachable and safe contact between electrical conductors. The function is, therefore, to conduct electrical energy between an input and output unit. However, to check error messages, they must be artificially generated. Thus, during commissioning, clamp connections are intentionally loosened with each other to check whether an error message is correctly displayed. Consequently, there are two states in which a functioning clamp can be connected or disconnected. In the above example with the security door, however, there were three states.

Finally, agents play an essential role in modelling. As mentioned at the beginning, the focus of the consideration of ontology is the modelling of manual activities in the production process. Information on which employee has carried out a step can be helpful if coordination is necessary. New colleagues can also ask for support in the execution if they know who to contact. Further conclusions are possible besides the information about which worker, e.g., carried out the process, see object relation ‘ro:participates_in’. For example, as in the underlying research project, it is possible to differentiate between the level of experience. Also conceivable are characteristics or abilities of persons, e.g., whether additional qualifications are available. In the BFO, the class ‘bfo:role’ exists. The CCO further specifies this concept through ‘cco:OccupationRole’. ROXANA also adds further specifications, e.g., electrician, commissioning engineer, technical documentation, or project manager. The role of persons in organisations can be necessary according to the rights management in a software application.

5.4. Mapping to the IOF Core model

The IOF Core ontology represents a domain mid-level ontology built upon the structures of the domain-independent top-level ontology, the BFO. In adhering to BFO, it initially follows the fundamental differentiation between entities that persist through time (continuant) and entities whose manifestations are time-dependent (occurrent).

The formation of IOF stems from the endeavour to develop interoperable ontologies for manufacturing. A hierarchical structure with BFO as the top, generic foundation is central to this pursuit. BFO functions as a top-level ontology, which is refined by mid-level ontologies, thereby serving as a modelling basis for specific applications in manufacturing.

IOF Core incorporates refinements of BFO, such as those about material entities, informational entities, or time-dependent quantities in the production context. In the context of development efforts associated with IOF, there are also endeavours towards domain-specific reference ontologies that build upon the mid-level concepts of IOF Core. These efforts involve contextualising domain-specific reference ontologies, such as the supply chain.

The first version of ROXANA uses selected CCOs, but some concepts within IOF Core are also based on model elements of these mid-level ontologies. Not only the structure based on superordinate top and mid-level ontologies, but also the use of existing and established ontology references contributes to interoperability in the ontology landscape. Therefore, we have published a second version mapped to the model elements of the IOF Core. The model conformity with the IOF Core enables participation in future development steps within the framework of the IOF Core but also promotes their establishment as a domain mid-level ontology. The authors were aware of IOF’s development efforts during the research project. However, no publication existed that we could use at that time.

Figure 9 shows the model concept, ontological references, and standards that we underpin with ROXANA through colour coding and block elements. ROXANA, as the lowest level of abstraction (dark blue), underpins the IOF Core as a modelling reference for the production domain (light blue), which in turn is a specification of the BFO as a top-level ontology (green). As the IOF Core uses the BFO, we still retain the standard. However, we implement only some CCO concepts in the second version. The main reason is that integrating industry-relevant concepts in the IOF Core makes parts of the CCO superfluous. The object relations are particularly affected by this. Figure 10 shows the ROXANA specifications of the existing object taxonomy on the left-hand side.

Figure 9. Abstract concept representation of the ROXANA ontology with labelling of used concepts of the IOF Core reference and the BFO standard in a block representation.

Exemplary entities show the relations in ROXANA in version two based on the IOF Core and the BFO. Colour blocks illustrate the use of BFO and IOF Core for the depicted entities in ROXANA.

Figure 10. Overview of the mapping of object relations in the taxonomy; version one based on BFO and CCO; version two based on the IOF Core building on the BFO structure.

The defined relations of ROXANA in version one based on the BFO and the CCOs on the left-hand side are contrasted with those in version two based on the BFO and the IOF Core on the right-hand side.

The right-hand side shows the assignment to the IOF Core structure. Only ‘cco:is_cause_of’, including the subrelation ‘rox:change_stasis’, has been integrated to map the cause-effect relationship with partial temporal simultaneity. The question may arise regarding what speaks against modelling via a temporal subrelation such as ‘has occurent part’ (corresponds to the label designation). According to the subclass definition of ‘iof:ManufacturingProcess’, a manufacturing process is executed by an agent following a defined specification. The authors regard state changes to machine components as a sequence of processes.

Consequently, an agent causes a state to change as well. In the research project, however, it was observed that such a change can be the consequence of a previous state form. A concrete example: the agent removes a plug from the coolant tank during a process, which leads to the state ‘PlugCoolantValveNotConnected’. However, if the plug is not connected, the spindle, pump, and various processing units switch off automatically. Therefore, the switch-off directly results from a previous action without any manual intervention. A triple in this use case would be: ‘rox:PlugCoolantValveNotConnected rox:change_stasis rox:SpindleOff’.

Figure 10 also shows that ‘is about’ and the inverse ‘is subject of’, including the associated subrelations adapted around the IOF Core IRI. As a result, the Roxana relations under ‘prescribes’ and ‘prescribed by’ were subordinated under the corresponding IOF Core relations. In its first version, ROXANA introduced the relation pair ‘value_of’ and ‘has_value’ to model data values. As the IOF Core has now integrated such a relation with ‘isValueExpressionOfAtSomeTime’ and ‘hasValueExpressionOfAtSomeTime’, these relations are no longer required with version two. What remains are the relation pairs in connection with state expressions. We make a fundamental distinction between partial temporal relationships and the relationship between the state and the material object. The former is a specification of ‘has occurrent part’ or the inverse ‘occurrent part of’. The second is a subrelation under ‘has participant at some time’ or the inverse with ‘participates in at some time’.

We have also transferred the classes to the IOF Core structure. ROXANA contains specifications for the technical material units and the categorisation of human-bound activities. In version one, we used ‘cco:Artifact’ as the superordinate parent class. In version two, we use the semantic counterpart with ‘iof:PieceOfEquipment’ to categorise the ROXANA classes from the first version.

The CCO assigned the class ‘Act’ under the abstract BFO ‘process’ and differentiated between ‘IntentionalAct’ and ‘UnintentionalAct’. ROXANA set up the ‘ActOfCommissioning’ class as a subclass of ‘ActOfArtifactAssembly’. The superordinate class is ‘ActOfArtifactProcessing’ and contains further specifications irrelevant to the ROXANA scope. In contrast to this extensive differentiation, the IOF Core appears more compact. Figure 11 shows that the IOF Core with ‘AssemblyProcess’ contains a semantic counterpart to ‘ActOfArtifactAssembly’, so we have mapped the ROXANA concepts under this class.

Figure 11. The class taxonomy under ‘occurrent’ with ROXANA specifications of manual commissioning steps in bold; version two, based on the IOF Core taxonomy.

An excerpt from the ontology editor Protegé shows the class taxonomy under ‘occurent’ with the categorisation of human activities in version two of ROXANA as subclasses under ‘Assembly Process’ from the IOF Core.

Just as the object relation in the first ROXANA version ‘has_value’ is already omitted by modelling in IOF Core, the associated class concept ‘Variable’ is also omitted. IOF Core creates a semantic assignment to ‘InformationContentEntity’, even if this has the status ‘provisional’ in the last valid version. The authors do not want to create an independent assignment. Instead, we decided to orientate ourselves on the developments and findings of the IOF committee.

6. Application examples from production practise

6.1. Competency question 1: error analysis

We would like to briefly explain the role of error messages using a practical example. In short, error messages indicate a non-function. Such messages are not desirable when operating the system, as they prevent an activity from continuing. However, error messages also fulfil a safety-relevant aspect and can contribute to maintaining the machine’s functionality. During commissioning, the machine is not only assembled but also tested. The commissioning engineers deliberately cause error messages to check whether they appear correct.

As these are customised machines, the error messages and the associated error number, address, and other details are also specific to the machine. In practice, error number ranges are provided for one type of error. Where possible, the commissioning engineers assign the same number for the same or similar type of fault. However, depending on the design, numbers may already be assigned. In the ontology, a query, according to Figure 12, can provide information about past project error numbers.

Figure 12. Excerpt from GraphDB with SPARQL query and the associated results for determining the temporal precedence relationship of machine errors; with ROXANA version one.

The excerpt shows the query in the upper area and the results in table form in the lower area. The table consists of two columns and shows between which process steps there is a precedence relationship.

On the production line, the dependencies of error messages could be important. Error messages occur with a process. In the ontology, this connection is modelled by ‘rox:machine_error_is_part_of’. The temporal precedence relationship is modelled by ‘precedes’, corresponding to ‘BFO_0000063’. This relation has the characteristic of transitivity. This means that if ‘A precedes B’ and ‘B precedes C’, the conclusion can be drawn that A comes before B. The addition of a ‘+’ is used to take chained transitive precedence relations into account, see Figure 12. For demonstration reasons, we have limited the query to the project with the number 58013-4. It can be seen in the first row, e.g., that error 11 occurs in the safety control system before error 2. For reasons of clarity, we have not shown the complete results table.

6.2. Competency question 2: order of steps with states of technical components

In addition to the individuality of the systems, the further development of machines can lead to a deviation in the process steps across the projects. However, new findings among the workers can also lead to changes in the process flow. If problems occur during commissioning, previous project approaches can help resolve them. The commissioning engineer can check old documentation for clues or ask colleagues for empirical values. The latter is only sometimes an option due to staff leaving the company, whether due to retirement or a change of employer. Moreover, as mentioned earlier, documentation is only sometimes available or in the level of detail required for troubleshooting.

The query in Figure 13 shows the determination of the steps under the sub-process plan ‘:GeneralWorkMainSwitchON’. The states of material artefacts associated with these steps are also part of the query. A state can be a necessary prerequisite for executing a step, see ‘rox:has_state_part’, or the result, see ‘rox:output_state_is_part_of’. The results table shows that executing the ‘CL1.5’ step requires several state forms. The empty column for ‘StateOutput’ means that the steps do not result in a state change.

Figure 13. Extract from GraphDB with SPARQL query and the associated results for determining the sub-steps associated with a plan, including states of material artifacts as incoming or outgoing parts; with ROXANA version two.

The section shows the query in the upper area and the results in table form in the lower area. The table consists of 4 columns labelled: step, state part, state output and project number.

6.3. Competency question 3: state as a process requirement

As mentioned at the beginning, commissioning engineers deliberately create states of machine components to test functionalities, including safety-relevant aspects. Individual circumstances on site can lead to people changing the process sequence of work steps. In the project, the company had to reorder a component during commissioning. Valuable time passes before the delivery arrives, resulting in costs.

The query in Figure 14 aims to determine which work steps the components are put into a desired state for a subsequent process. We have also restricted the search to the project with ‘58013-4’ for demonstration reasons. This excerpt shows that step 3.8 changes the state of several components for step 3.12, including the motor protection switch E93-Q1 of the chip conveyor. If the commissioning engineer has not yet carried out step 3.8, he should do so before carrying out step 3.12.

Figure 14. Extract from GraphDB with SPARQL query and the associated results for determining which steps (previous step) create the prerequisite of the state components for a subsequent process step; with ROXANA version two.

The section shows the query in the upper area and the results in table form in the lower area. The table consists of three columns and illustrates in columns two and three in which process step a status form in column one is caused or required.

7. Implementation in a real-life expert software application

We have developed a prototype assistance system for commissioning special machines and implemented the ROXANA ontology model into the framework. These commissioning workflows vary widely depending on the specific machine, its configuration, and the context in which it is supposed to be used in production. The assistance system that builds upon ROXANA aims to support these workflows by providing a structured yet flexible approach to the process that allows users with differing proficiency levels to navigate the necessary tasks quickly and ensures that all necessary steps are taken. Furthermore, users can annotate individual tasks with additional information during the commissioning, which could then be used to improve future commissioning.

The prototype of this assistance system consists of three modules: 1) a frontend, implemented as a web-based application that can be accessed with a web browser, 2) a SPARQL server, and 3) the so-called Ontology Service, which is responsible for mapping the data between the ontology and the web interface as well as for the business logic required for instantiating new commissioning projects.

We used a SPARQL server provided by Apache Jena TDB2 to persist the ontologies and their instances. The SPARQL server and the Ontology Service were connected via Apache Jena Fuseki. Furthermore, instances created during the usage of the assistance system are stored there, as well. The Ontology Service is written in the programming language Python using the framework Django (Django Software Foundation 2023). To reduce the complexity of the implementation of the frontend, this Ontology Service provides a Representational State Transfer (REST) Application Programming Interface (API) that the frontend can access and compile the respective SPARQL queries to access and manage the graph data persisted on the SPARQL server. That way, it supports Create, Read, Update, Delete (CRUD) operations on the graph data and provides the logic for the sanitation of user input as well as for the instantiation of a new commissioning project. Furthermore, it enriches data returned to the frontend by information according to the Hypermedia as the Engine of Application State (HATEOAS) approach.

This assistance system requires that the basic ROXANA ontology and a derived ontology specific to the context of use (e.g., the specific manufacturer the machines of which are going to be commissioned) are loaded onto the SPARQL server. The user may then create a new commissioning project by specifying the machine configuration to be commissioned and a project number. Alternatively, instead of specifying the configuration, they may select a pre-existing project as a blueprint, if existing. The commissioning service then queries the SPARQL server for all ‘ActOfCommissioning’ template instances related to these specified parameters, and all subordinated instances. For each of these instances, a copy is created, and the relationships between the template instances are transferred to the respective copies, resulting in a checklist for the newly created commissioning project. Afterwards, the user may exclude specific tasks from these checklists or add additional ones that were not part of the template. If an existing commissioning project was selected as a blueprint, excluded, or added tasks are applied accordingly.

8. Summary and results

Despite increasing automation in production, manual processes still exist. Those processes are particularly prevalent for small and medium-sized companies for which machine process control is not worthwhile or possible due to the company’s size, the product’s individuality, or complexity. ROXANA is an ontology developed for the formal representation of these manual activities. In the sense of the generally known modelling principles, this ontology builds on existing ones (like BFO) or integrates them (like CCO). We presented version one, which uses the BFO and the CCO. Version two adapts the structures of the IOF and is, therefore, also based on the BFO.

ROXANA shows the possibility of modelling the complex manual processes in production and their representation in a taxonomy structure to the author’s knowledge for the first time. We have presented the model concept and explained it using examples. Furthermore, we have listed SPARQL queries for clarification and thus answered the competency questions posed at the beginning. Also, this paper presented the embedding of ontology in an assistance system and thus also shows an example of an actual application.

The main scope of specification in ROXANA for the class taxonomy consists, on the one hand of the types of manual activities. Through intensive research, we have identified 23 basic types of manual labour. The addition of further basic activities is possible. On the other hand, we have added physical entities based on the systems in the project so that it is possible to refer to the components of a machine, such as types of electronic parts.

9. Discussion and research perspectives

People are constantly learning. In the same way, the ontology is a continuous development process. To the best of our knowledge, we have developed the ROXANA ontology using representative application scenarios. However, we cannot rule out the possibility that we have already taken sufficient account of all company-specific phenomena in the modelling concept. Moreover, we will continue to test the ontology for other applications. At the same time, we would like to invite the interested public to participate, see link to the ROXANA GitHub Repository in section ‘Link’.

Concerning the class taxonomy, further clarification of the physical entities and the categorisation of human activities is likely. Mechanical systems are complex and consist of many different components. What is installed is also domain-specific, even if essential electrical components, such as switches or clamps, should probably be similar. With the increasing transfer to other applications, there will also be specifications for material components. In the case of manual activities, the granularity in categorising human actions may be a topic for discussion. The depth of the description also depends on the application. For example, setting a machine to a specific parameter value could be categorised under the concept of ‘ActOfCommissioningSet’. However, the combination and sequence of confirmation processes in the software application would also be possible. Given the current level of granularity, it is conceivable that the current class concepts are insufficient to describe other manual activities. If this is the case, an addition under the superordinate class ‘ActOfCommissioning’ is necessary. Furthermore, integrating the ROXANA ontology into a software solution, its instantiation with real data and finally, the practical added value has to be elicited.

One challenge in developing ontology was the differentiation between a planned and, therefore, yet-to-be-realised process and the process in practice. Commissioning, e.g., is planned before implementation. There are, therefore, ontological entities that represent this planning. In BFO, there is a fundamental distinction between ‘occurrent’ and ‘continuant’. In other words, concepts that are time-independent or time-bound in their existence. An actual process falls into the second category. In version one of ROXANA, we used the ‘Modal Relation Ontology’ of the CCO. This ontology contains a copy of the relations under a different prefix. This means that a planned process can be modelled as an ‘occurrent’ in the same way as an actual process. The IOF Core provides for ‘Action Specification’ and thus treats the description of a process as a ‘continuant’. The modelling of input and output variables, such as material artifacts, or process components, such as states of physical entities, cannot be carried out using the same relations. Instead, a concatenation of information entities takes place. The question is when a semantic description exists. To understand its meaning, the user must first identify what an information unit refers to. It differs when something is modelled as a process, state, or physical unit, which implies an association. What it is, is already apparent from its affiliation. Of course, annotations could be added to support human comprehensibility. However, an annotation is there to support and not to replace the explanation of the meaning of an entity. There is also the question of how to model a context such as ‘:Process1 :has_state_part StateA’ via information entities concerning the relation. We see a third possibility as promising. A real and a planned process are modelled as an occurrent entity. The former can serve as a template for an action instruction according to an ‘ActionSpecification’. The execution by a person and the implementation in practice leads to an actual process. We expect the integration to be part of version three.

However, ontology modelling ultimately involves a great deal of effort. Companies need ontology experts who, together with domain experts, formally secure and represent the knowledge. A significant part of the effort consists of knowledge elicitation and structuring, representing separate research fields. Nevertheless, part of the research effort must focus on simplifying knowledge modelling to strengthen the use of ontologies in practice. There are already publications dedicated to text-based modelling. However, further research is needed to bring it into practical application. The ontology as a component in an application or research area can help strengthen the application reference. For example, part of the work of Arena et al. on human resource management looks at the task analysis of human activities (Arena et al. 2018). The categorisation of human work steps into basic activities in ROXANA can contribute to the formal representation of manual processes.

We found that companies are asking themselves what the advantage of ontologies is. Publications such as El Kadiri et al. also address this topic (El Kadiri and Kiritsis 2015). We have noticed that ‘classic’ table-based databases are more prevalent in companies and people’s minds. Therefore, using a graph-based database is accompanied by a departure from the familiar and requires a remarkable explanation of the practical benefits. Now, the people who use a software application usually differ from those who develop it. Therefore, the visualisation of added value is a question of software functionality. Users might sometimes conclude that the advantage of graphs is limited to the functions contained in the software. How could they do without graph knowledge?

More and more widespread applications are needed to demonstrate the advantages of graphs from the user’s perspective. Furthermore, this does not include chained SPARQL queries or extensive graph structures. Once again, it becomes clear that the user’s challenges and needs must be considered in UX/UI development, regardless of whether the database is graph- or table-based.

10. Conclusion and managerial insight for the industry

Companies and management are facing the challenge of a shortage of skilled labour. There is a staff shortage, and valuable expertise is lost when employees leave. This knowledge can also help when it comes to training new employees. In today’s world, interoperable solutions are needed to meet the challenges of adaptive production environments. As mentioned initially, society has changed into a knowledge society 4.0. Knowledge is a valuable corporate resource. Solutions are needed that not only digitally secure the knowledge resource but also implement it in an intelligent application. It is not enough to ‘secure’ knowledge in a partially structured collection of documents. Knowledge is neither digitally accessible nor retrievable in this way nor organised in management. Instead, using data enriched with semantics could make a difference for companies in a knowledge society 4.0.

We were able to show that we could make the knowledge accessible and usable in a machine-readable format in an ontology. The implementation in a software application also demonstrated the benefits of business practice. As in many companies, the departments are interlinked. Commissioning, e.g., is the final step into which design, procurement, or mechanical assembly flows. Therefore, the process's structural and formal representation could also have added value for these departments. One advantage is the use of a standardised vocabulary. Depending on the domain, people use different terms for the same context. This and the frequent lack or absence of communication between these areas make it difficult to identify errors or opportunities for improvement.

Internationally, there is already an endeavour to create a generic model reference for the representation of production. Even the creation of standards and references is a long process. Establishing them in practice also takes time. Companies should be aware that using ontologies is not a decision in favour of an application. Instead, it creates the basis for machine learning-based evaluations and analyses, among other things. Once again, the advantage of graph-based databases lies in the adaptivity in the representation and extensive data linking. However, flexibility also means complexity. Moreover, complexity can be countered with ontologies.

As North’s knowledge ladder has already shown, data and information form the basis for employee’s knowledge and expertise. We have realised that the question is how high the economic added value of ontologies is. To answer this question, we first need to know how much it costs the company to make inadequate use of knowledge or even a lack of knowledge. For example, how much extra time do employees need to find information for a problem such as plant maintenance? Furthermore, how much does machine downtime cost? Companies are rarely able to quantify this in total.

11. Geolocation information

This ontology results from a research project with small and medium-sized enterprises in Saxony, a federal state in Germany.

Acknowledgement

We want to thank the small and medium-sized enterprises for the intensive discussions and the support provided during the company processes as part of the research project. This work gave us a comprehensive overview of the challenges in human-based process steps.

Link

For more details on ROXANA and modelling examples, please refer to the associated public GitHub repository: https://github.com/pfaffmanja/ROXANA-ontology. The authors explicitly welcome the participation of the interested public and the scientific community.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Data availability statement

The ROXANA ontologies, as well as instructions and notes, are available on the public GitHub repository. The ontology also contains annotations as definitions, comments, and practical examples. The company-specific documents on the commissioning process itself cannot be made public due to confidentiality obligations and to protect the competitiveness of the companies.

Additional information

Funding

This work was part of the research project AdapDat (adaptive data-based commissioning of special production machines) funded by the European Commission (European Regional Development Fund) and the Free State of Saxony Germany under grant number 100365076.

Notes on contributors

Manja Mai-Ly Pfaff-Kastner

Manja Mai-Ly Pfaff-Kastner studied industrial engineering, specialising in mechanical engineering, at the Chemnitz University of Technology in Germany and the Universidad Nacional de Cuyo in Mendoza, Argentina. During her studies, she gained professional experience in technical project management in R&D at VW in Wolfsburg and R&D at Volkswagen Group of America in Chattanooga, USA. Today, she is a research assistant, group leader and doctoral candidate in the ‘Digitalisation in Production’ department at the Fraunhofer Institute for Machine Tools and Forming Technology IWU in Chemnitz. In her doctoral thesis, she is developing a novel concept to contribute to digitalising human expertise and decision-making in production.

Tim Wunderlich

Tim Wunderlich is a software architect with expertise in formalising dynamic production processes and the associated semantic data models. His work further involves designing and implementing resilient and scalable software architectures. Having a background in cognitive psychology, his interests additionally include user-centred assistance systems, particularly AR and VR technologies.

Ken Wenzel

Ken Wenzel studied Computer Science at the Chemnitz University of Technology, focusing on software technology and compiler construction. After his studies, he started working as a research associate at the Fraunhofer Institute for Machine Tools and Forming Technology IWU in Chemnitz. His main interests are applying semantic technologies within the field of smart production and designing flexible data architectures. Since 2017, he has been the head of the department ‘Digitalisation in Production’. He gained a doctorate degree in manufacturing engineering in 2022 with his thesis about the application of semantic web technologies for the mathematical modelling of production systems.

Steffen Ihlenfeldt

Steffen Ihlenfeldt studied Mechanical Engineering at the Technical University Braunschweig. From 1997 to 2015 he worked at the Fraunhofer Institute for Machine Tools and Forming Technology IWU, holding various management positions. In 2015, Prof Ihlenfeldt took over as head of the Chair of Machine Tools Development and Adaptive Controls at Technical University Dresden. In 2021, he became director at Fraunhofer IWU Chemnitz and is responsible for the Scientific Field ‘Production Systems and Factory Automation’. Prof Ihlenfeldt is corporate member of the International Academy for Production Engineering (CIRP) and member of the German Academic Association for Production Technology (WGP).