A benchmark dataset with Knowledge Graph generation for Industry 4.0 production lines

1.Introduction

The Industry 4.0 (I4.0) production line is a trending research topic that necessitates the automation of the production line to meet smart manufacturing [34]. The goal of I4.0 is to use various technologies and artificial intelligence to make better use of resources and optimize production [29,36]. Meanwhile, in I4.0, the sensing technologies hosted on machines generate an immense amount of data in different types and formats. During the manufacturing process, the machines and tools required to be automatically handled according to the context of the retrieved information to enhance the efficiency of the overall production line [33].

In the I4.0 manufacturing production line., various operators require access to different types of information according to their interests and roles. For instance, an engineer from the maintenance department would be involved in knowing the Critical To Process (CTP) or Key Process Index Variables (KPIV) information of machines on a daily basis. The CTP or KPIV of machines includes information such as their nominal power requirement, current temperature and/or pressure, and operating frequencies of the tools. On another side, an engineer from the production department would like to analyze the product’s quality and would be interested in retrieving the CTP parameters set down by the maintenance department for each product. These operators can be facilitated with such information retrieved from information systems.

In order to enable the production line operators to access such information, the semantic web is one of the possible solutions. The semantic web has transformed the current document-based web into a more intelligent system. The semantic web combines the data and content into a structured web environment, allowing software agents to execute tasks autonomously for users. The semantic web uses ontologies, RDF model and syntax, SPARQL Queries, etc. to represent the information in a machine-processable structure, in which ontologies sit in the centre among other building blocks [1]. According to Feilmayr et al. 2016 and Gruber et al. 1993, an ontology can be defined as a formal, explicit specification of a shared conceptualization that is characterized by high semantic expressiveness [8,14]. The assertion of the data into ontology becomes a KG. According to Hogan et. al. 2021, a KG can be thought of as a graph of data intended to gather and convey knowledge of the real world, with nodes denoting objects of interest and edges denoting relationships between these objects [15]. The semantic web recommends best practices for exposing, sharing, and integrating data, information, and knowledge, known as linked data. The data distributed under an open license is referred to as linked open data [22]. In the last decade, KGs have been widely used in many fields, e.g., geography, health care, education, news, social networks, cyber-security, and I4.0 [39].

Industry 4.0 Knowledge Graphs (I4.0 KGs) have been receiving significant attention recently, and many researchers are working to build them such as manufacturing production lines KGs. However, most of the time, they are limited to a specific use case [20]. These use cases are based on two possibilities (1) researchers are using synthetic data, or (2) a use case is coming from an industry based on their private company data. There are a few datasets available for Industry 4.0 production lines, such as Bosch dataset.44 The Bosch dataset reflects the production line processes including its machines and their operations, and targets applications such as predictive maintenance. This dataset does not provide any description of its attributes and therefore, it is very ambiguous and hard to understand. For example, L3_S36_F3939 stands for a feature measured on line 3, station 36, that has a feature number 3939. However, there is no explanation about what sort of station and feature they are. Moreover, private company data is only accessible to enterprise researchers. For the earlier use case, there is an issue with reproducibility and making the data findable, accessible, interoperable, and reusable, also known as the FAIR principles. However, to the best of our knowledge, there is no open dataset (and associated KGs) for an Industry 4.0 production line.

Based on our investigations, the goals of this research work are (1) to prepare a realistic production line dataset and (2) to generate a semantic representation of the data with the help of the Reference Generalized Ontological Model (RGOM). To achieve these goals, collaboration is made with the football industry (explained in Section 3) and the results contribute to

The dataset is evaluated using the FAIR evaluation tool,55 obtaining a total FAIR score of 79% (Findable: 77%, Accessible: 100%, Interoperable: 75%, Reusable: 62%).

The results demonstrate the efficiency of the RGOM against the dataset that could be utilized by the researcher’s community. Table 1 illustrates some of the key facts about the Football production line dataset. Additionally, this could motivate other industries to set up a linked data-based production line.

The rest of the paper is organized as: Section 2 reviews the Related work by exploring state-of-the-art techniques in this area. The dataset from the football production line is analyzed in Section 3. An approach to integrate the production line data is illustrated in Section 4. The use case to verify the RGOM adaptability with the generated dataset is presented in Section 5. Section 6 explains the extension of the benchmark to other use cases. Finally, the paper is concluded in Section 7.

2.Related work

In recent years, a number of initiatives have been undertaken to semantically represent the I4.0-based production line domain knowledge where an application is built on top of it. An overview of the existing literature on using datasets following ontologies to construct a knowledge graph is presented in this section. A summary of the ontologies and the datasets being used to develop an I4.0 production line KG is presented here.

2.2.I4.0 production line with KG generation

In line with smart manufacturing, many other studies have empowered ontologies with applicable use cases and explored the advantages of KGs on top of ontologies to configure, manage, and optimize the production line. In 2018, in order to represent knowledge of manufacturing resource reconfiguration, a configuration-based ontology was developed using the Web Ontology Language (OWL) [34]. This research focuses on the integration of manufacturing Cyber-Physical Systems (CPS) equipment based on an ontology-based resource integration architecture. Ontology-based architecture is evaluated using data generated by the smart manipulators as clients and data stored on the Raspberry Pi as servers. A KG is constructed by mapping the data instances to ontology terminology. Kovalenko et al. 2018, presented AutomationML ontology to enhance the engineering processes in CPS design [23]. The ontology addresses the CAEX section of the AutomationML standard. However, the authors did not explain how their ontology can be used with data instances to generate a KG. In another study, Liebig et al. 2019 proposed a KG pipeline for industrial automation and control [24]. A KG is constructed by combining data collection, data cleaning, and the use of various technologies. There has been a revolution in KG-based approaches in academia as well as in manufacturing companies, such as Bosch, and Siemens [13,16]. Irlan et al. 2020, proposed Bosch I4.0 KGs on the top of a set of domain ontologies [13]. The purpose of their work is to integrate data from different silos in order to address the problem of interoperability. According to Kalaycı et al. 2020, a Semantic Integration at Bosch (SIB) framework was introduced to integrate Bosch manufacturing data to analyze the surface mounting process pipeline [20]. To experiment with their framework, they developed surface mounting to map production line data. In all, KGs have become a potential enabler to facilitate I4.0 production lines, as can be seen from the various initiatives and interests. However, there lacks a clear explanation of the data instances to generate KGs and the mapping mechanism among the datasets, ontologies and KGs.

Fig. 1.

Flow of a single production process. The black arrows show the process flow in the production line and the blue arrows show the data flow from the sensors to the monitoring unit. 1◯ In a single process, the TPU roll is fed into Laser Cutting Machine. 2◯ Laser Cutting Machine converted the TPU roll into patches. 3◯ Patches are printed via squeegee by the oval printing machine. 4◯ Printed patches are cut into panels. 5◯ Back sides of panels and cores are sprayed with glue. 6◯ Glued panels and cores are passed by the heated conveyor to form a moulding machine. 7◯ Cores and panels are moulded. 8◯ Balling shaping machine gives football shape to the moulded cores and panels. 9◯ The gaps between the panels are sealed with glue via a Ball seam glue machine. 10◯ The glue is dry by the heat-activating conveyor and 4 footballs are produced.

To summarize, the current literature demonstrates an emerging trend towards the implementation of ontologies and KGs to I4.0 production lines. Nevertheless, many studies did not demonstrate how to populate the ontologies with data instances to construct a KG. There also lacks public access to the existing knowledge resources, particularly the datasets that constitute the ontologies. As a solution to the lack of availability of production line datasets, a collaborative effort is established with the football manufacturing industry with the goal of obtaining realistic data. In order to construct a KG, dataset instances are populated into RGOM. The development of a KG based on this methodology can serve as a motivation for other smart manufacturing industries.

3.Football production line

This section explains the data acquisition and dataset construction. The production floor consists of several production lines, each consisting of 9 machines with five operators (humans) performing manual operations. A typical football construction requires Thermoplastic polyurethane (TPU) roll, football cores, printing colours, glue, Laser Cutting Machine, Oval Printing machine, High-Frequency machine, Glue Spraying machine, Heat activating Conveyor machine, Forming Moulding machine, Ball Shaping machine, Ball Seam Gluing machine, and Heat drying machine. During a single production process, these machines perform different processes on different materials and produce four footballs as a finished product. Figure 1. depicts the single process flow of football production and the flow of the sensors data in a manufacturing production line.

The sensors installed on the machines in the I4.0-based production line generate data that are sent to the monitoring unit. In order to collect the first real instance of the data, several meetings were held with production line managers and engineers of Forward group limited regarding the operations of the machines, resources, processes, and production. It generally involved recording the power consumption, temperature, pressure, location, and type of process performed at a given timestamp by the machines. Also, the working status and rotational speed of the motor and other attributes were also recorded. Table 2 depicts the tools and machines parameters which include machine name, timestamp, temperature, pressure, power, laser die, bed, squeegee, heater, high-frequency die and many others.

Initially, the collected data were stored in a file comprising two types of attributes such as static attributes and variable attributes under the supervision of production line engineers and managers. Static attributes contain those attributes of the machine whose values remain the same in each process of manufacturing e.g. Machine model, process location, motor ID etc. On the other hand, variable attribute value changes in each process based on the performance condition of the machine, e.g. temperature, pressure, diameter, etc. Using the minimum and maximum values as well as the real value measured by the sensor, we are able to obtain the realistic data with the help of uniform probability distribution in each sub-processes. Uniform probability distribution takes input in a range bounded between the possible minimum and maximum value describing the possible likelihood and values of a variable [21]. The values of generated instances are computed using base values plus the random value generated using uniform probability distribution in the range [a,b]. For instance, to generate a temperature value of machine1, we can formally compute a new temperature value Temp2 from the previous value Tempprevious as follows:

Where a and b are the maximum and minimum reference values from the production line supervisors and engineers. For example, to compute an instance of the temperature for machine1 during the TPU roll-cutting process, a base value of temperature is taken that is 41° celsius. Using the uniform probability distribution f(x)=random.uniform(a,b) in equation (1), where a is set to 1 and b is set to 5, this provides an f(x) of 0.25. Upon summing the f(x) value with the previous temperature value, it gives the temperature value for machine1, 41.25° celsius. The same procedure is used for other variable attributes. The values generated are consistent with actual observations and have been verified and validated by the engineers on the production line.

After clarifying the two types of attributes regarding the entire production line, the data type for each machine is analyzed and generated. As mentioned before, the production includes 9 machines that are explained in the following subsections.

4.An approach to Integrate the I4.0 production line data

The acquired data becomes increasingly available in the data storage. However, most of the time, the raw data are stored in various formats, disregarding their semantics and relations. It may restrict the usability of the data, e.g., querying information, data analysis, etc. Therefore, there is a pressing need to represent this data in a semantic representation, i.e., Linked Open Data. Semantically enriched representation of data or KGs adds meaning and context to data through ontologies and vocabularies that make it more easily understood and interpreted by humans and machines [25]. This leads to several benefits including improved data integration, data understanding, data interoperability, and faster discovery of knowledge via more powerful data querying and analysis [7,10,19]. We present the new release of the I4.0 KG dataset, comprising comprehensive semantic descriptions and values of the machine’s processes involved in a single football production line.

Fig. 2.

An illustration of the approach to integrate data.

This section describes the approach to building I4.0 KGs from the football production line data that can be queried by any staff in the production line. Figure 2 illustrates the workflow for constructing the KG which is comprised of four layers, Layer 1: Unstructured Data Sources, Layer 2: Knowledge Graph Construction, Layer 3: Football Production Line Knowledge Graph, and Layer 4: Users and Applications. The following subsection describes the layers and the interaction of the different components.

4.2.Layer 2: Knowledge Graph Construction

The goal of building an I4.0 KG can be accomplished with core and domain ontologies of the Reference Generalized Ontological model (RGOM), to which the data from Layer 1 is mapped to construct a KG. Figure 3 depicts the pipeline to construct I4.0 KGs. The RGOM and data sources are given as input to the reader component. The reader component read the ontology resources i.e., class, object and data properties from the RGOM and parsed data records from the data sources. The data instances are mapped with RGOM classes and properties by the mapping components that are described in Section 4.2.2. The subsections below describe the components involved in Layer 2.

Fig. 3.

Pipeline for knowledge graph construction.

4.2.1.RGOM

The development of the football production line KG is based on our initial work that is about RGOM [37]. RGOM is a generalized ontology representing the essential concepts of I4.0, illustrated in Fig. 4. One of the main characteristics of RGOM is its modular design and is the combination of domain ontologies (device ontology, process ontology, manufacturing ontology, etc.) and core ontologies (sensor ontology, time ontology, location ontology) which is the extended version of the work by Giustozzi, F. et al. [12]. The use of core ontologies helps to benefit from the context of the data and provides added value information. Additionally, RGOM is inspired by the standards adopted by Reference Architectural Model Industry 4.0 (RAMI4.0) which is of key importance for developing the I4.0 applications.

Fig. 4.

Figure illustrates some of the main classes, sub classes and relations of domain and core ontologies in RGOM ontology.

Table 3

An overview of RGOM highlighting key concepts and relations, along with references to other reused ontologies

RGOM components	Reused concepts (References)	RGOM new concepts/relations
Manufacturing ontology	[3,12,17,30]	Material, Container (Pellet), isProcessedby, isPlaceOn
Machine ontology	[3,12,27,30]	MachinePart, Tool, Capabilities, Current, Power, consumesPower, hasInputMaterial, hasTool, useTool
Process ontology	[3,12]	ManualProcess, MeasurementProcess, ConveyorOperation, FeederOperation
Product ontology	[12]	Service, isGivenTo
CoreOntology	[4,12,26,28]	X

In order to develop the KG based on RGOM, only the most relevant ontologies to the I4.0 are selected which are the core ontologies and domain ontologies. Figure 4 depicts the concepts and relations reused from relevant existing ontologies (ssn:Sensor, ssn:Property, sosa:madeObservation, sosa:observes, time:Time, time:hadTime, dc:isPartOf), while there are several newly defined concepts such as Power, Tool, Part, Service, etc. Due to the page limit of the paper, we could not show the full picture of the RGOM in detail, however, Table 3 provides the overview of RGOM with emphasis on key RGOM concepts/relations as well as other reused ontologies and their references. Moreover, the modules in the RGOM ontology are discussed as follows.

Manufacturing ontology The manufacturing ontology objective is to semantically describe the resources in the manufacturing production line. The Staff concept represents all the people participating in the production activities, i.e., technicians, operators, and managers. The ManufacturingFacility concepts characterize different physical entities and hardware modules in the factory. The concepts of the production line are decomposed into; Workstations contains the physically integrated machines; Cell is the combination of the workstation to perform a complex task; a line includes cells. This decomposition presents a potential reconfigurable processing line. Additionally, this taxonomy makes it possible to describe the manufacturing facility context at various next levels such as the characterization of a line or to illustrate the context of the cell that belongs to that line. The physical entities in the manufacturing facility are the resources linked to other ontologies via object properties.

Machine ontology The machine is the main resource to process raw or refined material into semi or finished production on the production line. The machine performs the process with the help of tools by itself or with intervention from the human. It can be either a processing or assembly machine processing a raw or refined material or assembling the refine parts. The machine is a manufacturing facility and is part of the workstation.

Process ontology A set of tasks or operations completed by a resource is known as Process(es). The process(es) performed by a resource(s) can be controlled operations as well as machining or assembly ones. The process ontology represents the fundamental taxonomy of all the processes executed in the manufacturing and is specified with contextual such as process happensIn location, process appliesTo a product, machine performProcess process, etc.

Product ontology Product ontology covers the basic taxonomy related to products based on the IEC 62890. The components are the parts assembled by an assembling machine into a finished product. The customers can place an order of one of the two, i.e., for service to the bought product or buying a new product.

Core ontologies Establishing the context of certain manufacturing tasks is difficult and is a major problem in the industrial domain since it includes many different entities linked to time and locations. Time, Location, Process, Machine and Resource are the primary concepts to semantically represent the manufacturing knowledge in line with domain ontologies. In addition, the terminology reused from the sensor ontology i.e. SSN enhanced the semantic representation of the collected sensor data. The concepts for measuring the sensor data are reused from the Ontology of units of Measure (OM) [28]. Thus, the use of core ontologies e.g, Time [26], Location (adopted from [12]) and Sensor [4] with the domain ontologies present useful information regarding various situations, i.e., inquiring about the status of the motor at a particular time (Listing 3).

4.2.2.Populating RGOM with data

Now we discuss populating RGOM with Data which adds the structured data from the production line to the ontological terms of RGOM, i.e., classes and properties. Algorithm 1 outlines the data population process, starting with initializing the ontology classes and properties required for the data population. It then goes through each record in the data, the values in the columns and creates individuals and their associated object/data properties. Using the semantics defined in the ontology model, an object property is chosen to form a triple with the subject and object individuals. For example, as can be seen from Fig. 2 in Layer 2 of the data population into ontology terms, the algorithm gets the class type ManufacturingMachine and ManufacturingProcess from the ontology file, and iterates over the data records in the data file. In a single iteration, the columns machine1 and machine1_process from the spreadsheets are created as a subject and object with the aforementioned class types, respectively. Based on the condition, the parsed literal values are linked via data property to the resources. For instance, object property, such as performsProcess, from the ontology file which links the resources to form a triple i.e., data:LaserCuttingMachine smo:performsProcess data:CuttingTPURollProcessNumber51. Moreover, the values in the database column can also be mapped to the attributes of the KG via column mapping using R2RML [5].

Algorithm 1:

Populating data to rgom

As a result, data will be successfully populated to RGOM. In Fig. 5, we show a snippet of the machine_9 individuals along with their features i.e processMaterial, hasTools, consumesPower, performsProcess, isInLocation, hosTools.

Fig. 5.

Illustration of machine 9 instance with their attributes instances.

5.Use case: RGOM adaptability

In this section, a use case on the KG-based dataset is presented. The use case deals with the adaptability of RGOM on realistic football production line data. The RGOM semantically integrates the heterogeneous data of the machines in a football production line into I4.0 KG88. The data from the I4.0 KG is queried without requiring extra time and manual effort.

The production process of a football contains nine machines and each performs different sub-processes (Fig. 1). The data produced during this process contains the domain knowledge of the machines, tools hosted on the machines, processes performed on them, tools deployed on the machines, tool’s critical parameters, and contextual data generated by the sensors hosted on the machines at some timestamp. The approach presented in Section 4 is followed to semantically integrate the data. At first, we gathered the data sources containing the data about all the machines which are then analyzed in line with the RGOM classes and relations. The main classes and relations of RGOM are depicted in Fig. 3. Next, the data is populated to the ontology terms, i.e., classes and relations with Jena API99. Upon the population of data into ontology terms, an RDF triple store is obtained, known as an I4.0 KG.

To produce a single football, an average of 1730 triples, 1355 logical triples, and 233 declaration triples are produced. In one hour of the production line, a total of 9 main processes are executed, producing 36 footballs and 22150 triples on average from 2903 individuals.

Besides, three I4.0 KG-based datasets are generated to provide the researcher’s community to evaluate their tools and techniques. These datasets are comprised of ten days, twenty days, and thirty days of data from a football production line. The types of machines and their parameters are explained in Section 3. The total number of axioms, logical axioms count, declaration axioms count, and individual count in each KG are illustrated in Table 4. The number of classes, object properties, and datatype properties are the same for each KG.

After the construction of the KG, several queries are provided by the domain experts to find the usefulness of the KG. The SPARQL endpoint at the application layer of I4.0 KGs paves the way for different applications to access the required information embedded in the KG. Given a production line where the job at hand is to utilize the query drawn from Listing 1 in order to access the type of machines and their names involved.

Listing 1.

Query to retrieve the machines involved in the production line

Figure 6 shows the results returned from the Listing 1 query. It can be seen from the figure that the production line consists of a single assembly line and eight processing machines, each with their name.

Fig. 6.

Listing 1 query provides the number of machines involved in the production line with their names.

Furthermore, the production line manager can utilize the Listing 2 query to find the tools present on a machine. The result of the Listing 2 query is shown in Fig. 7. It can be seen from the figure that machine 2 has a name and uses different types of tools such as one motor, three beds, three heaters, and three squeegees. The query fetches machine 2 name and different types of tools that resides in the KG.

Listing 2.

Query to retrieve the tools hosted on machine 2

Fig. 7.

Listing 2 query provides tools hosted by machine 2.

Similarly, an engineer from the maintenance department wants to query the KG for CTP parameters to check the current observation of the sensor or the status of the motor. For instance, a maintenance engineer can retrieve the status of a motor at a particular period of time by using the query in Listing 3. The query fetches the status of the motor at different timestamps as illustrated in Fig. 8.

Listing 3.

Query to retrieve the status of machine 2 motor at certain time period

Fig. 8.

Result returned by the query in Listing 3.

Listing 4.

Query to retrieve the CTP parameter (Temperature) with time

In order to retrieve the temperature (a CTP parameter) query in Listing 4 is utilized. The reuse principle of Linked Open Data has been followed by reusing the SOSA vocabulary as depicted in list 4. Figure 9 shows the fetched results of the query in Listing 4.

Fig. 9.

Listing 4 query provides the retrieval of the temperature (a CTP parameter).

Furthermore, a query in Listing 5 is used to find the total number of processes performed by a machine and the total number of tools that each machine used during a given time. The query returns information about all the machines with the total number of processes they performed during a given time and the total number of tools used by them, shown in Fig. 10. For instance, in the list, machine_1 has performed a total of 100 processes and used a total of three tools during the time from 12:55:13 to 14:36:04.

Listing 5.

Query to retrieve the count of processes performed by machines and count of tools used by them during a time period

Fig. 10.

Listing 5 query provides the count of processes performed by machines and count of tools used by them during a time period.

6.Extension of the benchmark to other use cases

The current work showcases the potential of applying the RGOM to a larger picture. The concepts introduced in RGOM can be utilised for the majority of production lines which will facilitate wider use of our approach for generating KGs for different use cases. For example, this approach can be extended not only to other similar manufacturing processes such as volleyball and rugby ball production, but also to other more generic production lines that incorporate welding processes. This can help other industries map their customised data into RGOM and construct an industry-specific KG. Additionally, to build KGs for a different manufacturing industry, one should adopt the RGOM framework to add definitions of required classes and relations. For instance, in ongoing work, we have been collaborating with Bosch to incorporate RGOM in their welding production line. We have created new concepts such as WeldingMachine as Machine, WeldingRobot, WeldingGun, and Electrode as Tool, WeldingOperation and MaintenanceOperation as Operation, and Workpiece as Material. This developed welding ontology demonstrates the adaptability of RGOM [38]. Adopting a similar mechanism will help digital transformation for those who have not set up a Linked Data-based production line.

The I4.0 KG dataset can be utilised in predictive maintenance [2]. For example, one useful use case of the I4.0 KG dataset is predicting the temperature of a machine. In manufacturing factories, the temperature of the machine is of high significance and critical. During the process execution, the tools are operating under a set point. The increase in temperature can adversely affect the machine which impacts the product quality. The assessment of the temperature information enables the setting up of condition-based machine tool temperature monitoring and prevents any impact on the quality of the end product. Furthermore, the I4.0 KG can be used by deep learning models to carry out entity matching, nodes classifications, link prediction, and knowledge graph completion [18,31,35].

7.Conclusion

The purpose of this research is to introduce a benchmark dataset with KG generation for I4.0 production lines, and specifically leverage the advantages of ontologies and semantic annotation of the data to showcase how the I4.0 industry can benefit from KGs and semantic datasets. We identified that the current research work has been limited to two use case possibilities, (1) using synthetic data and (2) an Industry-based use case that comes with private company data. private company data is made accessible only to people associated with the enterprise. Moreover, the earlier use case faces an issue of reproducibility and FAIR principles. This work tries to bridge the gap between academic researchers and industry by providing the former (first case) access to data that is not easily and publicly available. To address this limitation, a dataset is designed by acquiring realistic data from a football production line. An automated solution is developed that maps the dataset attributes with RGOM terms, i.e., classes and relations in the form of I4.0 KGs. The results of the competency questions on the I4.0 KG illustrate the adaptability of the RGOM in a production line. The adaptability of RGOM demonstrates the usefulness of the dataset, Hence, it can be extended to similar production lines such as Volleyball and Rugby ball.

Further studies need to be carried out in order to validate the dataset on other ontological models. Further research should be undertaken to apply KG embedding and diffusion techniques to have a complete I4.0 KG.

Funding

This publication has emanated from research supported in part by a grant from Science Foundation Ireland (SFI) under Grant Number SFI/16/RC/3918 (Confirm), by a grant from SFI under Grant Number SFI 12/RC/2289_P2 (Insight), and by a grant from the European Union under Grant Number 958371 (OntoCommons). For the purpose of Open Access, the author has applied a CC BY public copyright licence to any Author Accepted Manuscript version arising from this submission.