A Semantic Framework to address the Evolution of Semantic Models for Condition Monitoring in Industry 4.0

Tracking #: 3253-4467

Franco Giustozzi
Julien Saunier
Cecilia Zanni-Merk

Responsible editor: 
Guest Editors SW for Industrial Engineering 2022

Submission type: 
Full Paper
In Industry 4.0, factory assets and machines are equipped with sensors that collect data for effective condition monitoring. This is a difficult task since it requires the integration and processing of heterogeneous data from different sources, with different temporal resolutions and underlying meanings. Ontologies have emerged as a pertinent method to deal with data integration and to represent manufacturing knowledge in a machine-interpretable way through the construction of semantic models. Moreover, the monitoring of industrial processes depends on the dynamic context of their execution. Under these circumstances, the semantic model must evolve in order to represent in which situation(s) a resource is in during the execution of its tasks to support decision making. This paper proposes a semantic framework to address the evolution of semantic models in Industry 4.0. To this end, firstly we propose a semantic model (the COInd4 ontology) for the manufacturing domain that represents the resources and processes that are part of a factory, with special emphasis on the context of these resources and processes. Relevant situations that combine sensor observations with domain knowledge are also represented in the model. Secondly, an approach that uses stream reasoning to detect these situations that lead to potential failures is introduced. This approach enriches data collected from sensors with contextual information using the proposed semantic model. The use of stream reasoning facilitates the integration of data from different data sources, different temporal resolutions as well as the processing of these data in real time. This allows to derive high-level situations from lower-level context and sensor information. Detecting situations can trigger actions to adapt the process behavior, and in turn, this change in behavior can lead to the generation of new contexts leading to new situations. These situations can have different levels of severity, and can be nested in different ways. Dealing with the rich relations among situations requires an efficient approach to organize them. Therefore, we propose a method to build a lattice, ordering those situations depending on the constraints they rely on. This lattice represents a road-map of all the situations that can be reached from a given one, normal or abnormal. This helps in decision support, by allowing the identification of the actions that can be taken to correct the abnormality avoiding in this way the interruption of the manufacturing processes. Finally, an industrial application scenario for the proposed approach is described.
Full PDF Version: 

Minor Revision

Solicited Reviews:
Click to Expand/Collapse
Review #1
Anonymous submitted on 14/Oct/2022
Minor Revision
Review Comment:

Dear Authors
I appreciate the addressing of some of the comments, I was previously the second reviewer.
I do not agree with the dismissal of the concern in the usage of the terminology around ontology evolution.

I agree with reviewer 3 on the discourse of using ontology evolution and stream reasoning. This is not to criticise your approach or implementation of your idea. This is only about the usage of the appropriate terms. As you state in your response and in the introduction, your model doesn’t handle the addition, modification or removal of new classes. Hence, the semantic model does not evolve in any way (as Reviewer 3 has pointed out). I do agree that the addition of entities and relation would normally still be considered ontology evolution, however, this is only the case outside of the stream (reasoning) context. When an ontology is considered as a stream, the underlying definition of the stream is the addition of new information (entities and relationships between them). The community does not consider this to be evolution of the semantic model and it should not be called as such in your manuscript either. I ask the authors to please reconsider and stick to the domain of stream reasoning rather than trying to combine them and mix and match the terms from the two communities.

Side-comment: It would make reviewing of your revised manuscript much quicker if you would (in future) highlight the changes not only in the response letter but also in the manuscript itself, e.g. by colouring the changed part of the text in blue.

Review #2
Anonymous submitted on 24/Oct/2022
Minor Revision
Review Comment:

Thank you to the authors for their responses to our suggestions. One of the things noted in the first review was issues with getting the owl file to run on GitLab, this has now been corrected and as a result we have some additional comments for your consideration. These are listed below in no particular order.

1. Can the authors clarify if / how the Stream reasoning engine discussed in the paper is making inferences beyond the asserted facts within the ontology. Please can you check that you are actually use the `constraints' in the queries? Is it possible that the queries can be redefined in C-SPARQL? If so, how does this leverage the ontology?

2. The proof of concept does not actually instantiate the situations the way they describe in the text, it simply outputs to console. The ontology file that is read in appears to already include all of the situations.

3. Please can you check your definition in the paper of ManufacturingFacility compared to what is in the owl file?

4. We may have missed it but OWL file does not appear to actually include many (any?) of the axioms mentioned in the paper text (other than subsumption).

5. Would your response to the comment about the `Translation' module be strengthened by an explicit reference to Figure 1 in the paper to avoid any confusion?

6. You refer to `Situations' as being concept descriptions but they do not appear to be generalisable as they seem to be tied to specific temperature properties of specific items, for example. So how do you intend to describe more generalised situations relating to all pieces of equipment of a particular type in particular contexts?

7. There is discussion about semantically enriching things, but we note that important semantics are missing such as types of things, sensor configuration, situations, properties, constraint content, units of measure, etc. How could an engineer design appropriate thresholds if they do not know if a temperature is in Celsius or Fahrenheit, for example?

8. For us running the reasoner does not work as the temporal values are not consistent with the range constraint added to the data properties. Please check this.

9. There are temporal instants with multiple time values attached. This cannot be true. For example, instance time:t-obs-S\_E\_temp-1 has 3 timestamps.

10. In the response to Review 1 about the transitivity of 'is part of' you say it is transitive, but the ontology file disagrees and the SPARQL queries also do not take into account transitivity. Please can you look into this.

11. Perhaps reconsider the use of the word 'model evolution' if you restrict yourselves only to adding new situation instances. That is not model evolution in any currently accepted use of the term.

12. The comment about the terms 'normal and abnormal situations' are not differentiated in the ontology, which is what Reviewer 2 was trying to get at. Perhaps another attempt to address this comment is warranted?

Review #3
Anonymous submitted on 31/Oct/2022
Review Comment:

I accept this paper having faith that the author will address the comments below (some in this version and others in future).

1) From rebuttal: "The approach proposed in the paper deals with the detection of abnormal situations, for which these situations must be defined in advance. These situations are defined in terms of observations that meet certain constraints and are interpreted as a whole according to spatio-temporal relationships between them and are not interpreted isolated. The value of each observation is interpreted in the context in which it was made to provide effective condition monitoring. Therefore, the aspects (parthood, location, and time) mentioned in the comment are important but also he concept of observation is key to the representation of the context and provide the notion of situation. Regarding the last sentence of the comment, we would like to emphasize that the objective of the proposed semantic model is not to describe a process but rather to describe the context of a process. Therefore, it is not relevant whether the instance of the process is a single instance or several instances of the same type of process."

If it is observed process then it needs to be distinguished from actual process, the actual process then may have different observations based on observation/measurement.

2) This is not addressed: "“The Time module comprises all information related to the current time and allows time-stamping all the context information that may change over time.” – if time is itself contextual, as previously mentioned, is time
information also time-stamped? "

3) From Rebuttal: "Regarding the example given in the comment, we are not sure what the reviewer means by p1."
It can be interpreted from the given domain restriction of hasDuration that p1 is a process.
"If p1 is a process and t1 is an interval, then t1 indicates the duration of the process p1."
Then does it mean this triplet doesn't need time-stamp. It is confusing which triples are time-stamped and which are not.

4) The covering axioms on Resource,... will not allow.
From Rebuttal: This has been corrected in the paper.
ManufacturingFacility ⊑ ∃operates−1 .Staff
⊓ (Line ⊔ Cell ⊔ WorkSation ⊔ Machine) Therefore, still has the covering axiom, 'Factory' cannot be declared as subclass of ManufacturingFacility.

6) “. . . the context of a Line and depicting the context of a Workstation that belongs to that Line” – The model does not tell what can be part of what. If Line, Cell, Workstation, and Machine are not constrained for the parthood then one can state that a line is part of a machine, which may not be true.
From Rebuttal: Line, Cell, Workstation, and Machine are disjoints classes.
That does not solve the problem. It requires some extra axioms: e.g., Workstation is partOf Only Cell.

7) From Rebuttal: It is not the objective of this paper to provide a complete formalization of industrial processes. The process module of our semantic model reuses concepts and relationships from other models oriented to represent industrial processes [44,47].
It may be the case that ontology development is not the aim but the real contribution of the paper is in the analysis of the data. But the ontology proposed here is not founded on rigorous ontological analysis.

8) From Rebuttal: "The concept Process refers to industrial-related processes. We believe that an observation is not a process, or at least it can be seen as the output of a process. We believe that the concept sosa:Procedure of SOSA could perhaps be considered as a process. The sosa:Procedure concept is not shown in Figure 2 as it is not fundamental to our approach."

The authors are advised not to use a generic label Process for a specific concept. It can be IndustrialProcess. If the authors believe that sosa:Procedure is a process, perhaps authors are conflating the specification of a process with process.

9) "If we consider a sensor as a resource then the two relations (locatedIn and isInLocation) are the same." Why not?

10) " abstractions of physical spaces it refers to representations of spaces [60], such as sectors of a factory, etc." Authors are advised not to use a generic label for a specific concept. Use FactorySpace / SectorOfFactory

14) "Yes, these concepts can be aligned with the geo:Feature class" - I could not find this reflection in the paper.

16) "Yes, they are." - I could not find this reflection in the paper.

17) "Background knowledge is the knowledge represented in the ontological model. If we consider the C-SPARQL query of listing 1, the line 14 ?m sosa:hosts sosa:S TG temp is background knowledge stored in the ontology. This means that a machine ?m hosts the sensor sosa:S TG temp. The ?m variable will be binding to a particular machine. " - Is this explanation included in the paper?