A semantic framework for condition monitoring in Industry 4.0 based on evolving knowledge bases

1.1.Main contributions of this article

These requirements motivate the proposal of a novel semantic framework to address the evolution of knowledge base in Industry 4.0. The proposed framework uses semantic technologies to represent the manufacturing domain with special emphasis on modeling the context of the resources involved in a factory. The proposed framework aims at detecting situations that can lead manufacturing processes in Industry 4.0 to failures and their possible causes. Through the detection of these situations and their causes, appropriate decisions can be made to avoid the interruption of manufacturing processes.

The first contribution is related to the development of the knowledge base; and the other ones are related to the management of the evolution of the knowledge base:

The rest of this paper is structured as follows. Section 2 provides a review of existing ontology-based models and systems developed for condition monitoring. Section 3 presents a framework to deal with the evolution of knowledge bases for condition monitoring in Industry 4.0. The approach includes the use of an ontological model for the representation of the entities involved in a manufacturing process, emphasizing the modeling of the context. Each of the components of the proposed framework are detailed as well as the interactions among them. In Section 4 an industrial application scenario for the proposed approach is studied. By means of it, we verify that (i) the proposed semantic model is generic and extensible to accommodate a wide spectrum of manufacturing processes, and that its modular architecture allows the description of manufacturing resources with different levels of modularity; (ii) the use of stream reasoning together with classical reasoning approaches allows the detection of abnormal situations as well as of their possible causes in a suitable way; and (iii) the exploitation of the lattice helps in decision making, by allowing the identification of the actions that can be taken to correct the abnormal behavior of the process. Finally, Section 5 gives some concluding remarks as well as some perspectives for future work.

2.1.Data-driven approaches to condition monitoring

With the development of big data related techniques and the ever-increasing availability of data, data-driven predictive maintenance is becoming more and more attractive. To extract useful knowledge and help to make appropriate decisions from huge amount of data, machine learning and deep learning techniques have been regarded as powerful solutions. The models obtained by applying those techniques perform like a black box that learn the behavior of physical assets directly from their operation data [32]. They have the ability for feature learning, fault classification and fault prediction. Within a data-driven approach, knowledge about machines are extracted internally from machine operation data, instead of externally from domain experts. In the following, we present works that are representative of the domain.

In [50], the authors present an Artificial Neural Network (ANN)-based fault diagnosis for rolling element bearings using time-domain features. Five vibration signals from sensors are used to extract five time-domain features as the input of the designed ANN. The experimental results show that the accuracy can reach 62.5%-100%. Benkercha et al. [9] propose an approach based on the building of a Decision Tree to detect and diagnose the faults in grid connected photovoltaic system (GCPVS). The features used include temperature, irradiation and power ratio, and the class labels contains free fault, string fault, short circuit fault or line-line fault. Experimental results indicate that the diagnosis accuracy can reach 99.80%. In [60], Soualhi et al. apply the Hilbert-Huang transform (HHT) [28] to extract health indicator from vibration signals and utilized SVM to achieve fault classification of bearings. A method based on the evidential k-NN (EKNN) rule in the framework of evidence theory to achieve a condition monitoring and early warning in power plants is developed and presented in [15].

Several surveys on different data-driven approaches for fault detection and diagnosis exist. Zhao et al. [73] provide an overview of Deep Learning based machine health monitoring systems. All the systems presented are aimed at fault identification and classification. Zhang et al. [72] present more recent results on Intelligent fault diagnosis with small & imbalanced data, which refers to build intelligent diagnosis models using limited machine faulty samples to achieve accurate fault identification. In addition, a series of survey papers focus on the fault diagnosis for a specific type of components, e.g., bearing, rotating machinery, wind turbines [7]. In [71], Zhang et al. systematically summarize the existing literature employing machine learning (ML) and data mining techniques for bearing fault diagnosis. Liu et al. [36] provide a comprehensive review of AI algorithms in rotating machinery fault diagnosis from the perspectives of theories and industrial applications. In the same direction, a more recent review of the role of AI in rotor fault diagnosis is presented in [38]. In particular, it is based on fault-wise analysis, providing a proper categorization of rotor failures, rather than on component-wise analysis.

The aforementioned works have given interesting contributions related to the field of fault detection and diagnosis, but most of them are equipment specific. They monitor the behavior of different properties of a machine. They are suitable and efficient when consuming data streams to detect abnormal patterns in the values of a machine’s property (e.g. temperature, vibration, etc.). However, they have two drawbacks: (i) the need, in advance, for a huge amount of annotated data for model training [17,65], most of the research is conducted in laboratories with equipment in test benches or using one of the few public datasets; and (ii) the lack of explicit model to explain decisions. It is therefore difficult to interpret the data and it also complicates the interoperability and re-usability of the models.

2.2.Knowledge-based approaches to condition monitoring

Many traditional condition monitoring systems and fault diagnosis systems make use of a priori expert knowledge and deductive reasoning processes [45]. Expert knowledge is exploited to build an ontology that formally describes concepts and relationships that exist in the industrial domain. Different ontologies have been built for monitoring tasks such as predictive maintenance and health assessment systems [41]. Ontology-based modeling allows: (1) knowledge sharing between computational entities by having a common set of concepts, (2) logic inference by exploiting various existing logic reasoning mechanisms to deduce high-level concepts from raw data, and (3) knowledge reuse by reusing well-defined ontologies of different domains. Ontologies can be employed to represent different machinery systems and devices, and can be combined with various existing rule-based reasoning algorithms to achieve monitoring and fault diagnosis. This is done based upon the evaluation of on-line monitored data according to a set of rules which is pre-determined by expert knowledge. Usually, rules are expressed in the form: IF ⟨antecedent⟩ THEN ⟨consequence⟩. In this way, the consequence can make changes that affect the system that is being monitored, if the conditions in the antecedent are met. In the following, we make a review on several knowledge-based approaches for condition monitoring.

Recently, Gul et al. [27] propose a condition monitoring based approach for risk assessment in a rail transportation system by using a fuzzy rule-based expert system. In [33], Kharlamov et al. design a rule-based language for equipment diagnosis in ontology mediated data integration scenarios such as industrial IoT. Its advantages include the easy formulation of diagnosis programs with hundreds of pieces of complex equipment. Berredjem et al. [10] propose a fuzzy expert system to localize bearing faults diagnosis as well as distributed faults. The fuzzy rules are automatically induced from numerical data using an improved range overlaps method.

A more recent approach in this direction is the one proposed in [14], the authors introduce a novel hybrid approach that combines data mining and semantics to facilitate predictive maintenance tasks in manufacturing processes. This approach uses chronicle mining to predict the future failures of the monitored industrial machinery, and a Manufacturing Predictive Maintenance Ontology (MPMO) with its rule-based extension is used to predict temporal constraints of failures and to represent the predictive results formally. However, this approach does not consider the possibility to represent the evolution of a manufacturing process and the rule base. This makes it difficult for the predictive maintenance system to be able to adapt to dynamic situations over time, e.g. change of context. Although these approaches could be considered as data-driven, data mining technologies are here used to elicitate knowledge that will be exploited later.

Another rule-based model named Adaptive Neuro-Fuzzy Interference Systems (ANFIS) is applied for monitoring wind turbine SCADA (Supervisory Control and Data Acquisition) signals in [53,54]. In order to obtain turbine condition statements, the authors implement rules given by an expert who is familiar with the behavior of the turbine, typical faults and their root causes. There are two types of rules: generic rules used to highlight anomalies, and specific rules providing specific condition or potential root cause. Schmidt et al. [55] develop a semantic framework, using an ontology-based approach for data aggregation, to support cloud-enabled maintenance of manufacturing assets. Xu et al. [70] propose an ontology-based fault diagnosis model to integrate, share and reuse fault diagnosis knowledge for loaders. A loader is a self-propelled heavy machinery having for main function to push and lift (load) ground pieces.

Ontologies provide a way to integrate, share and reuse of domain knowledge, but other reasoning methods have to be integrated with ontologies to achieve predictive maintenance. Rule-based reasoning can be employed in order to achieve monitoring and diagnosis. These rules are built from expert knowledge, or are extracted from the analysis of large data sets, as mentioned above. However, knowledge-based approaches have difficulties in dealing with new (unknown by experts) faults and acquires complete knowledge to build a reliable set of rules.

Ontological models for the manufacturing domain A review of the existing knowledge-based condition monitoring systems is given in the previous section. In this section, we give an overview on the development and usage of ontologies in the manufacturing domain. These ontologies were defined with distinct purposes and, therefore, describe different types of information related to that domain. The development of a knowledge-based condition monitoring system requires domain knowledge about manufacturing processes to be represented in a formal way, thus making this knowledge usable by the system. To achieve this goal, semantic technologies, especially ontologies with their rule-based extensions, have shown promising capabilities for formalizing knowledge in various domains [44,57].

A typical manufacturing system can be characterized according to three main notions: Product, Process and Resource [37]. In [43], authors have developed a product ontology, named ONTO-PDM. It provides a semantic layer to business, design and manufacturing product-related information. ONTO-PDM harmonizes the product-related knowledge and standards, and this harmonization has shown positive results in solving the interoperability problems among different enterprises and applications. Other works in this direction are: OntoSTEP (ONTOlogy of Standard for the Exchange of Product model data) [8], which allows the description of product information mainly related to geometry; and MCCO (Manufacturing Core Concepts Ontology) [67] that focuses on interoperability across the production and design domains of product life-cycle. It provides some core classes in categories such as ManufacturingProcess, ManufacturingFacility, ManufacturingResource and Feature.

Like ONTO-PDM, the Process Specification Language (PSL) ontology [26] is another notable development work in the area of product information modelling. The PSL ontology covers several domains such as manufacturing, engineering and business processes. In this section we only focus on the manufacturing domain. Even though it mainly focuses on fundamental concepts for representing manufacturing processes, the ontology also provides a basis for the formal description of elements and entities that constitute a Process. The foundational elements of the core of the PSL ontology are four primitive classes (Activity, Activity-occurrence, Timepoint, Object), three primitive relations (participates-in, before, occurrence-of) and two primitive functions (beginof, endof). From the manufacturing product point of view, the notion Product could be deemed as a sub-concept under the core concept Object in the ontology. The PSL ontology provides a robust semantic foundation for modelling manufacturing product information. Furthermore, as indicated by the name, the PSL ontology is a powerful approach for the representation of manufacturing processes.

Other ontologies have been developed to enhance the performance of product information modeling in the manufacturing domain. As the PSL ontology, these ontologies include the notions of resource and process. Among them, the MASON [35] and the ADACOR [11] ontological models are considered as pertinent. The MASON ontology presents a detailed conceptualization mainly focused on the products because it was used for cost estimation of the production of mechanical parts. MASON is an upper ontology for representing what the authors consider the core concepts of the manufacturing domain: products, processes and resources. As a result, the main classes of MASON are Entity, for specifying the product; Operation, for describing all processes linked to manufacturing; and Resource, for representing concepts regarding machines, tools, human resources and geographic resources. The ADACOR Ontology, developed as a part of the ADACOR architecture, provides a refined conceptualization to model operations, production plans and work orders regarding customer orders. The ontology is not openly available. Hence to be applied outside of the ADACOR project, the ontology has to be rebuilt with the information provided in the documentation. The SIMPM (Semantically Integrated Manufacturing Planning Model) ontology [59] is an upper ontology that is also focused on the representation of production plans. It models the fundamental constraints of manufacturing process planning: manufacturing activities and resources, time and aggregation.

Besides the ontologies presented above, there exist other ontologies that are more focused on modeling manufacturing processes and resources. The P-PSO (Politecnico di Milano Production Systems) ontology [22] considers three aspects in the manufacturing domain: the physical aspect (the material definition of the system), the technological aspect (the operational view of the system) and the control aspect (the management activities), for information exchange, design, control, simulation and other applications. Thus, its main classes are Component, Operation and Controller, which model the aforementioned three aspects, as well as part, Operator and Subsystem. The MSDL (Manufacturing Service Description Language) ontology [3] allows to describe manufacturing services. More precisely, a ManufacturingService is seen as a service that is provided by a Supplier and that has some ManufacturingCapability, which is enabled by some ManufacturingResource and delivered by some ManufacturingProcess. Another ontology with similar purposes to MSDL is MaRCO (Manufacturing Resource Capability Ontology) [31], that defines capabilities of manufacturing resources. Its main class is Capability, which is specialized to cover both simple capabilities (e.g. Fixturing, SpinningTool) and combined capabilities (those that require a combination of two or more simple capabilities, e.g. PickAndPlace, which requires Finger-Grasping or Vacuum Grasping, Moving and Releasing). Another interesting work is the one presented in [16]. It proposes a base ontology to represent a production line. The base ontology integrates four ontologies: (1) the device ontology, with concepts such as Machine; (2) the process ontology, with a taxonomy of the different Operations performed by the technical equipment; (3) the parameter ontology, with concepts such as QualityofService; (4) the product ontology, with the product information.

The presented ontologies define terms and relations for modeling the manufacturing domain, such as machine, process and the possible relations between them. The ontologies previously described do not allow representing the sensors attached to the company’s resources and the properties they measure, although the sensors are also fundamental for anomaly detection on production lines and reflect the correctness of mechanical system conditions. In addition, these ontologies do not allow the representation of the context of the machines and processes. This is important to determine whether the observations collected by sensors represent abnormal behavior or not.

As mentioned in the introduction, IoT is a key element of Industry 4.0. Nowadays, it is possible to use sensor networks to detect and identify a wide variety of observations, from simple phenomena to complex events and situations. However, the lack of integration between these sensor networks often isolates important or relevant data. To deal with this issue, the Semantic Sensor Web (SSW) approach provides tools that allow the integration of data from multiple data sources [58]. It introduces semantic annotations for describing: (1) the data produced by the sensors, introducing spatial, temporal, or situation/context semantics; and (2) the sensors and the sensor networks that provide such data. Furthermore, there are also works on defining suitable ontologies for data and sensors to enable both the integration of data from multiple sensor networks and external sources, and reasoning on such data. As an example, the W3C Semantic Sensor Network Incubator Group [29] developed an ontology to describe sensors and sensor networks, the Semantic Sensor Network Ontology (SSN). Another work in this direction is SAREF4INMA [19], that pursues interoperability with industry standards. The SSN ontology is further detailed in Section 3.1.

2.3.Discussion

Data-driven approaches, based on annotated data, and knowledge-based approaches, based on expert knowledge, for condition monitoring are discussed in this section. Furthermore, we have reviewed existing ontologies and their rule-based extensions for knowledge-based condition monitoring systems. Table 1 summarizes the domain coverage of the discussed ontologies. We evaluate the domain coverage and scopes of these knowledge models by examining whether the key concepts required for condition monitoring in Industry 4.0 exist and are formally described. We categorized these key concepts into five sub-domains: Manufacturing, Context, Change over time, IoT, and Monitoring and Diagnosis. For the Manufacturing sub-domain, the key concepts are Product, Process and Resource. For the Context sub-domain, the key concepts are Identity, Activity, Time, and Location. In this case, the term Activity, used in the definition of context proposed by Dey et. al. [21], refers to industry-related processes. Therefore, we consider Activity and Process as two related concepts. For the IoT sub-domain, Sensor and Observation are the key concepts. For the Monitoring and Diagnosis sub-domain, the key concepts are Situation and Cause. These concepts are the columns of Table 1, and the ontological models are the rows. If a check mark is placed in the table then the concept exists in the corresponding ontology. Otherwise, a cross mark is assigned.

After reviewing the ontological models mentioned previously, we recognize that none of them provides a satisfactory knowledge representation of the five required sub-domains. Some of these knowledge models focus on a narrow field, such as manufacturing resource planning and work orders, and they do not formalize context-related concepts, e.g., Activity and Location. Also, none of the existing ontologies provides a way of representing knowledge that evolve in time. To perform smart condition monitoring, the knowledge base should contain not only the machine-interpretable knowledge for characterizing the manufacturing entities or processes which are being monitored but also the knowledge about abnormal situations that are associated to failures. This motivates us to develop a more expressive and complete ontological model that provides a rich representation of the domain knowledge in the fields of manufacturing considering the notion of context.

In addition, the ontological models of the smart systems reviewed in this section are rather static. As described in the introduction, machines perform manufacturing processes in different contexts and these contexts change over time. According to the context in which a manufacturing process is executed, the rules that manage the process can change. In order to represent the fact that a machine is performing a process in these contexts, the knowledge base needs to evolve in time to represent this changing knowledge.

3.1.The context ontology for Industry 4.0 (COInd4)

Fig. 2.

The context ontology for Industry 4.0 (COInd4).

The development of a smart system requires that the domain knowledge is represented in a formal way. To achieve this objective, ontologies have been widely used to formalize knowledge about the industrial domain [44,70]. However, as indicated in the related work, most of these existing ontological models focus on a very specific field and sometimes lack a formal representation of context.

Our COInd4 ontology is a foundation of our approach. It represents the elements of the real factory, such as machines, processes and sensors, with special emphasis on modeling the context of operation of these elements. Relevant situations representing abnormal behaviors are also represented in the model. The goal of this semantic model is to represent the concepts and relations in the industrial domain to enable context representation and reasoning.

The ontological model is developed according to the methodology proposed in [66]. An overview of the classes and properties from the proposed ontological model is shown in Fig. 2. This ontological model is composed of six modules. They are described in more detail below together with the definition of their main concepts using Description Logics (DL) [5].

3.2.The Monitoring component

Certain situations that may lead to machine failures can be detected by interpreting observations in their contexts, for example, if an observation has an abnormal value it may be because another parameter is having abnormal values too. Let us consider the case where the temperature of a machine and the temperature of one of its components are being monitored. It is known that an increase in the temperature of the machine may be due to an increase in the temperature of its component, or vice versa. This allows the exploitation of expert knowledge about relationships between the values of certain parameters from the machines, from the processes and from their context for interpreting observations. Through the early detection of situations, the maintenance schedule can be adapted or further measures to prevent unexpected downtime can be taken.

The Monitoring component is responsible for collecting data from sensors in order to detect abnormal situations. It uses the knowledge base and modifies it as well. This component mainly uses the model for enriching data collected from sensors with contextual information. This allows to derive situations from context and sensor information of lower-level abstraction. Once an abnormal situation is detected, the situation together with the resources and the processes involved in it are added to the model; so that the model also represents which resources and processes are involved in the situation. This allows the model to continuously represent what is happening in the real manufacturing process.

In the following we explain the Translation and Temporal Relations modules. These modules, which are part of the Monitoring component as shown in Fig. 1, are involved in the detection of situations. The interaction between them, as well as with the ontological model, is also described.

In Section 4, the case study enables to explain in more detail how each of the modules of the Monitoring component works for data enrichment using context information as well as how the detection of situations defined by expert knowledge is performed.

3.3.The Diagnosis component

The Diagnosis component is responsible for determining the possible causes of the abnormal behavior. The crucial difference between monitoring and diagnosis relies on the nature of the output. Monitoring observes a discrepancy between the expected and detected behavior without exploration of the cause or fault underlying it [56]. However, in many domains such as Industry 4.0, monitoring and diagnosis are tightly coupled tasks: when monitoring observes an anomaly in the behavior, a diagnosis task is started, using the monitored information as input.

As the monitoring component, the Diagnosis component both uses the knowledge base and modifies it. This component mainly uses the model to determine the cause(s) of a detected abnormal situations. The association between the causes and the abnormal situations are obtained from expert knowledge. Once the possible cause(s) associated to the detected abnormal situation are identified, these cause(s) are linked to the detected situation in the knowledge base. This allows the model to represent which are the causes of an abnormal situation detected from the real manufacturing process.

The Diagnosis component has only one module called Cause Determination to determine the possible causes that caused an abnormal situation. The purpose of the Cause Determination module is to identify the possible causes that generated a situation detected by the Temporal Relation module. For this, two components are used separately: a Stream Reasoner and a Reasoner, as can be seen in Fig. 1.

Stream reasoning is more suitable to highly dynamic data than classical reasoning approaches. Thus, in the case where causes need to be determined in real-time, the Stream Reasoner is used to identify the causes. The association between the situations and their possible causes are stored in the ontological model and they are exploited by this module to return them. However, it is possible that some situations do not have identified causes in a real scenario, in which case the system notifies that the causes are unknown.

Therefore, in order to determine the possible causes of a situation classical reasoning approaches can be used. They provide other inferences that can help in determining the causes of a situation. More complex queries can be performed to the ontological model in order to extract information useful for cause determination. For example, it can be necessary to consider the Open World Assumption, which states that the absence of a statement alone cannot be used to infer that the statement is false. In this case, the Reasoner can be also used over the ontology to infer the causes, if the real-time requirement is not needed. This last option has some advantages over the previous one. If the cause is identified later, it is added as an instance to the ontological model and linked to the situation for future use. This is detailed in the section presenting the proof of concept.

In both cases, the Diagnosis component provides the Decision Making component with the detected situation together with the possible causes inferred by the reasoner(s).

3.4.The Decision Making component

Manufacturing processes are not always executed under optimal conditions. Nevertheless, they can sometimes continue their execution in degraded conditions without being completely stopped. Expert knowledge enables to describe these “intermediate” manufacturing conditions. The associated abnormal situations can have different levels of severity, and be nested in different ways. They can impact other processes or resources that participate in these processes and they can trigger other situations that represent a risk of major interruption of the manufacturing process or a risk of accident. Once an abnormal situation and its causes have been detected, the Decision Making component is responsible for determining and applying the adaptation strategies that are needed to improve the behavior of the production system. These strategies may include changes to the operation parameters of a machine or the launching of a maintenance task. This component also uses the knowledge base to determine which actions are possible to execute to improve the operating conditions.

In order to support the Decision Making component of our framework, it is relevant to consider which other situations can be reached from the current situation, to choose the most appropriate action. Therefore, we propose an approach to establish an order among the situations. The order among the situations is a hierarchy that depends on how situations’ constraints are correlated. This order represents a road-map of all the situations, normal or abnormal, that can be reached from a given one. In this way, it is possible to identify the actions that can be taken to correct the abnormality, considering that certain actions can modify the value of a property and thus change the state of the system, either by satisfying another constraint or, on the contrary, by not satisfying constraints anymore. The idea driving this proposal is to formally represent a hierarchy among situations leading to failures.

The proposed approach uses the lattice theory [18,24,39] to provide an expressive formalization to order the situations in a taxonomic way. In this way, the hierarchy of situations is formally extracted from the situations definitions. In the following, we firstly introduce the definitions that are necessary for the construction of the hierarchy of situations, and secondly, we describe the steps to automatically build this hierarchy from the situations definitions and its associated lattice.

3.4.1.Definitions

In order to formally represent a hierarchy of situations, let us consider the following structure ⟨S,C,R,T⟩ where:

• – S={s1,s2,s3,…,sn} is the set of all the situations,

• – C={c1,c2,c3,…,cm} is the set of all the constraints,

• – R⊆S×C is a binary relation that links a situation with a constraint, and

• – T⊆C×C is a binary relation that links a constraint with another constraint.

It is worth mentioning two aspects about situations that were defined in Section 3.1. The first one is that a situation defines an state of affairs that represents a particular scenario of interest and involves observations linked through spatio-temporal relationships, resources and processes. The second one is that situations are abstract, meaning that there may be different instances of a given situation. Instances of the same situation can happen during different periods of time and involve several resources, but they all satisfy the same constraints.

Set C contains all the constraints that are associated with one or more situations in the set of situations S. These constraints concern properties of the processes, machines, resources and of the environment in which the tasks are executed. For example, if we consider variables MC1_Temp and MC2_Temp, corresponding to the temperature of a component of a machine and the temperature of another component of the same machine, then MC1_Temp < 40∘C and MC1_Temp > MC2_Temp are constraints defined on them.

The binary relation R is used to establish that a constraint is involved in a situation. We write s1Rc1 to indicate that the constraint c1 is involved in the situation s1. The R relation is therefore built from the relationships between the situations and the constraints that are extracted from expert knowledge.

The sets S and C correspond to the Situation class and the Constraint class of our ontological model, respectively. The association between a situation and its constraints is represented through the hasConstraint relation in the ontological model, represented by the binary relation R.

Fig. 3.

Situations with constraints (R) and implications among the constraints (T).

The example below is used to illustrate the definition of the structure and the operators. Let us consider the following sets of constraints and of situations, with six constraints and six situations, respectively: C={c1,c2,c3,c4,c5,c6} and S={s1,s2,s3,s4,s5,s6}.

The corresponding R relation, built from S and C, is shown in the first two columns of Table 3. For example, the fourth line in this table indicates that situation s4 happens (first column) if constraints c2 and c5 are satisfied (second column). Another way to show relation R is depicted in Fig. 3. In this figure, we can observe how different situations share a part of the constraints in their definition. For example, s1 and s2 share constraints c1 and c6.

Table 3

Example of situations and associated constraints (in bold face the constraints that are implied by other constraints)

Situations	Constraints	T constraints
s1	c1, c3, c6	c1, c2, c3, c4, c5, c6
s2	c1, c4, c6	c1, c2, c4, c5, c6
s3	c2, c4, c6	c2, c4, c5, c6
s4	c2, c5	c2, c5
s5	c3, c6	c3, c4, c5, c6
s6	c1, c6	c1, c2, c6

Some constraints can be more general than others, i.e. include others. Such is the case with, for example, constraints c1 and c2 defined as MC1_Temp < 40∘C and MC1_Temp < 60∘C, respectively. If c1 is satisfied, then c2 is necessarily also satisfied. Furthermore, some constraints may imply other constraints due to physical properties extracted from expert knowledge or observations. For this reason, the T relation is defined to indicate that if a constraint is satisfied, then another one is also satisfied. We write c1Tc2.

Consider the implications among the constraints from the set of all constraints C shown in Fig. 3 (arrows labeled with T). These implications are inferred from the order relations (<, >, ⩽, ⩾), from observations, or extracted from expert knowledge. Taking into account these relations, the constraints associated with each situation are established as shown in Table 3 (third column). This allows to associate both explicit and implicit (implied) constraints to a situation.

In order to extend the formalization between a situation and a constraint to a set of situations and a set of constraints, two operators are defined below, based on the use of both R and T relations. These operators are defined on a set of situations or constraints because each situation can involve several constraints, and several situations can have constraints in common.

The first operator ⌈X⌉ enables the retrieval of the set of constraints associated to a set of situations.

Definition 1.

For a situation set X, X⊆S, let

⌈X⌉:={c∈C|∀x∈X:xRc∨∃c′∈C:xRc′∧c′Tc}

Considering situations s1 and s2 of the example presented above, the constraints related to both situations are ⌈{s1,s2}⌉={c1,c2,c4,c5,c6}.

The second operator ⌊Y⌋ conversely enables the retrieval of the set of situations involving a set of constraints Y.

Definition 2.

For a constraint set Y, Y⊆C, let

⌊Y⌋:={s∈S|∀y∈Y:sRy∨∃c′∈C:sRc′∧c′Tc}

This operator retrieves all the situations involving at least all the constraints in the set Y. Therefore, considering the example presented above, if the constraints c2 and c5 are considered, then the situations involving those constraints are ⌊{c2,c5}⌋={s1,s2,s3,s4}. Let us note that these situations may involve other constraints, e.g. s3 with c4 and c6.

3.4.2.The situation hierarchy construction

Using the elements of the structure ⟨S,C,R,T⟩ and the two operators ⌈·⌉ and ⌊·⌋ previously defined, the construction of the lattice representing the hierarchy of situations is detailed below.

In our approach, we group situations and their constraints as ordered pairs (X,Y) where X is a set of situations and Y is a set of constraints such that ⌈X⌉=Y and ⌊Y⌋=X. The first component of the pair is a set including all the situations that share all the constraints belonging to the second component. The second component is therefore the set including all the common constraints among the situations of the first component.

Algorithm 1

Calculate all the pairs (X,Y) where X⊆S, Y⊆C, ⌈X⌉=Y and ⌊Y⌋=X (setofPairs)

In order to find all the pairs and thus the nodes of the lattice, given a set of situations S, a set of constraints C, and relations R and T, Algorithm 1 is applied. Firstly, ⌈{s}⌉ is computed for each situation s∈S (lines 3–5). Then, for any two sets in this set of sets (consSet), their intersection is calculated. If this intersection is not yet contained in consSet, it is added to it (lines 6–12). This step is repeated until no new sets are generated. If set C of all the constraints and the empty set ({}) are not in consSet, they are also added to it (lines 13–18). These two sets yield the minimum and maximum nodes of the lattice, respectively. Finally, for every set O in consSet, ⌊O⌋ is computed (lines 19–21). In the end, set (setofPairs) of all the (X,Y) pairs that satisfy ⌈X⌉=Y and ⌊Y⌋=X is obtained.

Considering the example in Fig. 3 and Table 3, if the set of situations S and the set of constraints C are given as input to the algorithm, then the output are the nodes of the lattice shown in Fig. 4. Let us note that since the situations are predefined, the search for all pairs can be done offline. If a situation needs to be added, it is either added to a node or a new node is created. The addition of a new situation to the hierarchy has an impact on the structure of the hierarchy.

Fig. 4.

Lattice representing the hierarchy of situations (the situations defined exactly by all the constraints of the second component of the pair in the node are shown in bold face).

Once all the pairs are found, the next step is to order them in a lattice to build the hierarchy of situations. A lattice is an algebraic structure that consists of a partially ordered set in which every two elements have a unique supremum (also called least upper bound or join) and a unique infimum (also called greatest lower bound or meet). A partial order is a pair (P,⪯) where P is a set and ⪯ is a binary relation over P where ⪯ is reflexive, anti-symmetric and transitive. For our lattice, we consider L={(X,Y)|X⊆S∧Y⊆C∧⌈X⌉=Y∧⌊Y⌋=X} and the following binary relation defined over it:

Definition 3.

Let (X,Y) and (X′,Y′) be two pairs where X, X′ are sets of situations and Y, Y′ are sets of constraints. The situations in X′ are reachable from X if the constraints in Y∩Y′ are satisfied, noted as (X,Y)⪯(X′,Y′)⇔X⊆X′∧Y′⊆Y.

The hierarchy of situations has been proved to be a lattice [23]. The fact that the hierarchy is a lattice allows us to know the situations that can be reached from the current situation, knowing also the intermediate situations (this is inherited from the fact that a lattice is a partial order). In addition, let us suppose that two situations are happening simultaneously and these situations are represented in two different nodes of the lattice. Each set of situations from those nodes have a larger common set of situations with the constraints that are common to all situations in both sets of the two nodes. Dually, each set of situations have a smaller common subset of situations, which comprises all the constraints that all the situations in both sets of the nodes have. This allows to know from two situations that are happening, which situations can be reached by the production system: situations that satisfy the smaller number of constraints between the two situations that are happening (supremum) or situations that satisfy the greater number of constraints in common between the two situations that are happening (plus some other constraint(s)) (infimum).

The interpretation and exploitation of the lattice to support the decision making is detailed in the following section.

4.1.Case study description

The case study is based on a manufacturing production line (Fig. 5), named PL1, composed of four machines: M1, M2, M3 and M4. These machines and the production line are equipped with sensors. The sensors collect data on the properties described in Table 4. This scenario is formally represented using the ontological model introduced in this paper and it is shown in Fig. 6.

Fig. 5.

Production line.

Fig. 6.

Representation of the scenario using our semantic model.

Several abnormal situations that lead to failures in this scenario are defined by experts. Each of them is expressed as a set of constraints. We focus on situations covering the following types of failures: machines malfunctions and global malfunctions of the production line including hydraulic oil leakage and cooling system filter obstructions. The abnormal situations are describe in Table 5. The situations indicate different levels of severity. For example, situations s1 and s2 both represent situations that could lead to the same failure but s2 indicates a higher severity since the temperature threshold is higher than the temperature threshold for s1. In this case, higher impact actions should be taken.

4.2.Abnormal situation detection and cause determination

The situations defined are detected through C-SPARQL queries. In this section, we describe a particular query and see the effect it has on the ontological model when the situation is detected.

We must emphasize that for this case study all the data streams of the properties (ObservableProperties) defined in Table 4 are generated using the RDFStream class provided by C-SPARQL to generate RDF streams. Queries can also be executed on data streams that are generated and published by other systems or users, however, it is necessary to know the structure of the RDF stream to be able to execute queries on them.

The C-SPARQL query presented in Listing 1 has the purpose of detecting the situation S6, defined previously. The query name is registered on line 1 and prefixes used in the query are declared on lines 2 and 3. The query is executed on RDF streams that correspond to the properties C_Wtemp, TG_temp and G_temp in the time frame of 15 seconds, sliding the window by 5 seconds (lines 5–7). The chosen time frame is arbitrary and can be changed as desired. It produces pairs of values (line 4): the machine name (?m) and the production line of which it is a part of (?pl). In order to obtain the production line to which the machine belongs, we indicate in the query that the C-SPARQL engine must use our ontological model as background knowledge (line 8). Line 10 enables to obtain the production line to which the machine belongs, as shown in Fig. 7. To get the observation’s values, ?o1, ?o2 and ?o3 individuals are respectively bound with the data values ?v1, ?v2 and ?v3 through the appropriate properties (sosa:madeObservation and sosa:hasSimpleResult) (lines 11–19). Finally, the list of output pairs are filtered out to include only the ones where the observation’s values satisfy the restrictions in the FILTER clause (lines 20–23).

Listing 1.

C-SPARQL query to detect the S6 situation

Fig. 7.

Background knowledge and streaming data for S6 situation detection.

Once the situation is detected, it is added as an instance to the ontology as well as the relationships representing the resources concerned by this situation. Figure 8 shows a part (relevant to this case) of the ontological model before and after the detection of the S6 situation.

The next step is to determine the possible cause(s) of the S6 situation. The S6 situation is associated with a failure of the cooling system of the M3 machine. By expert knowledge we know that this situation can be caused by polluted filters in the cooling system. Therefore, the following rule is used to add this fact to the ontology. Figure 8(b) shows the added cause associated with the detected situation.

It is worth mentioning that in case the cause is not known beforehand, it can be added to the ontological model. Thus, the next time the situation is detected the cause is automatically determined.

Once the situation and its possible cause(s) have been detected, the next step is to make a decision to avoid the failure associated with the situation. To determine what action to make, we use the approach proposed in Section 3.4 to build the hierarchy of situations, based on the constraints on which the situations rely. The Fig. 9 shows the hierarchy of situations defined in the case study.

Fig. 8.

Part of the ontological model: (a) before detecting the S6 situation; and (b) after detecting it.

Fig. 9.

Hierarchy of the situations defined in the illustrative case study.

Having the situation detected and its possible cause, the Decision making component can use both to build a strategy to correct the abnormal behavior. For example, one action could be to replace the polluted filters which would lead to the constraints associated with the S6 situation no longer being met, i.e. correction of the abnormal behavior. In case this action cannot be carried out, the system or the operators can decide that the production line continues with the execution of its processes. This could lead to the S7 situation, satisfying the C_Wtemp>80∘C(c16) constraint, and thus requiring more urgent actions since the M3 machine would be closer to a failure. By observing the hierarchy, we can see that the behavior of the M3 machine could get even worse, since the S10 situation could also be reached if the Conv_temp>60∘C(c19) constraint is also satisfied. Unlike situation S6 and S7 which are associated with a failure of the M3 machine’s cooling system, situation S10 indicates that the M3 machine is having a global malfunction. So the strategy to follow could be more drastic as for example stopping the execution of the processes of the M3 machine, halting also the production of the whole production line (PL1).

Our approach provides the Decision making component with high level information such as situations and their possible causes from raw data. In addition, the hierarchy of situations allows visualizing the possible intermediate situations that the production system can reach. In this way, it is sought that the Decision making component takes appropriate actions to maintain the reliability and availability of the production line.

4.3.Discussion of the proposed framework

First, we evaluate the COInd4 ontology and then we discuss the limitations of the proposed framework for performing condition monitoring in Industry 4.0. We then discuss some of the limitations of the monitoring and diagnostic components of the proposed framework.

4.3.1.COInd4 ontology evaluation

We evaluate the ontology to check that it does not contain pitfalls and that it covers all the requirements identified in the introduction. In order to detect common mistakes done when developing ontologies we have used OOPS! [48]. In OOPS!, ontology pitfalls are classified into three categories: structural, functional, and usability-profiling. Under each category, fine-grained classification criteria are provided to cope with specific types of mistakes. The ontology is evaluated according to the following three categories:

• – Structural dimension focuses on mistakes detection on syntax and formal semantics.

• – Functional dimension considers the intended use and functionality of the proposed ontology.

• – Usability-profiling dimension evaluates the level of ease of communication when different users use the same ontology.

The evaluation of COInd4 with OOPS! has yield some minor pitfalls, that do not affect the consistency, reasoning or applicability of the ontology.

A first issue mainly regards “missing domain or range” errors inherited from the SSN ontology. The documentation of SSN states that not adding the domain or range to certain properties is a design decision not to be restrictive with them. However, we have decided to add the missing range and domains. Another minor issue is the case of the “recursive definitions”. In our case, it was needed to define several recursive relations, such as “A production equipment can contain another production equipment”. Therefore, we have not considered this pitfall as a mistake. The final evaluation of the COInd4 ontology by OOPS! appears in Fig. 10.

Fig. 10.

Screenshot of the proposed ontology evaluation results by OOPS!

The proposed ontology is generic and extensible to cover a wide spectrum of manufacturing services. Its modular architecture also allows the description of the capabilities of manufacturing resources at different levels of modularity namely, Machine, Workstation, Cell and Line.