=Paper=
{{Paper
|id=Vol-2900/WS4Paper4
|storemode=property
|title=Maintenance Terminology Standards: Some Issues and the Need of a Shared Framework for Interoperability
|pdfUrl=https://ceur-ws.org/Vol-2900/WS4Paper4.pdf
|volume=Vol-2900
|authors=Yves Keraron,Antoine Despujols
|dblpUrl=https://dblp.org/rec/conf/iesa/KeraronD20
}}
==Maintenance Terminology Standards: Some Issues and the Need of a Shared Framework for Interoperability==
https://ceur-ws.org/Vol-2900/WS4Paper4.pdf
Maintenance terminology standards: some issues and the need
of a shared framework for interoperability
KERARON Yves a, DESPUJOLS Antoine b
a ISADEUS, 21 rue Rollin, PARIS, 75005, France
b AFIM/EFNMS, 10 Rue Louis Vicat, Paris, 75015/ A.Reyerslaan80, B-1030 Brussel, Belgium
Abstract
Terminology is the first critical point cited by practitioners when they are questioned on the
need for standards. This paper gives a first analysis of maintenance terminology standards and
highlights some discrepancies between the definitions and the meanings of the same terms. To
standardize the meanings of the terms and to achieve the highest benefit of digital technologies
in industry, a shared framework is needed. This paper questions the possibility of such a
framework and the conditions of its benefit for industry.
Keywords 1
Maintenance terminology, Systems Engineering, Interoperability, Systems Ontology.
1. Introduction
Standards are critical for interoperability in maintenance. The benefit of a common terminology is obvious for
all stakeholders and industrials outlined the need for improved semantic models. However, we have to face
discrepancies in the terminology used in the different current standards. This problem is a general problem, which
limits the interoperability of data.
The process to agree on a terminology and to make formal definitions is a long process which needs to involve
discipline experts, terminologists, advanced data base experts. This can be a costly effort with a long Return Of
Investment.
We decided to join our efforts in the FORESEE cluster [1], grouping 6 H2020 projects on predictive
maintenance, as it makes sense to progress in a larger scope than a single project.
Our first task is to extract a core set of terms from relevant standards, with their definitions in order to analyze
their commonalities and differences in the aim to homogenize the terminology with the improved candidates in a
consistent way.
We intend also to feed this process with feedback from the FORESEE cluster projects: data models, mappings,
possible edition and use of ontologies.
Significant efforts have been recently made to explore the use of ontologies in industry and in its different
domains, and among them maintenance and its sub-domains [2]. The aim is to produce reference ontologies linked
to a top-level ontology to guarantee interoperability. We suggest here exploring further a systems ontology, as a
common ontology shared by all the various disciplines involved and focused on some terms of this systems
ontology. This latter approach fits well to the recent trends of Model Based Systems Engineering towards a
digitalization with clear benefits along all the lifecycle processes from design to maintenance and dismantling.
In chapter 1.2, we will give some outcome of our analysis of a core set of terms extracted from maintenance
standards,
Proceedings of the Workshops of I-ESA 2020, 17-11-2020, Tarbes, France
yves.keraron@isadeus.fr; antoine.despujols@free.fr
© 2020 Copyright for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR Workshop Proceedings (CEUR-WS.org)
In chapter 1.3, we will focus on a few terms and their definitions, which seem to us important to share, because
they are also used by other domains of engineering and highlights the need of clarification thanks to a shared
framework,
In chapter 1.4, before our conclusion, we come back to the definitions of what we consider as basic terms of a
shared framework based on Model Based Systems Engineering methods, and which should be appropriated by
stakeholders, especially maintenance actors, to improve maintenance processes digitalization and pave the way to
a consistent digital ecosystem including all the actors of the system lifecycle.
2. Core set of maintenance terms and their definitions in relevant standards
The standardization working group of the FORESEE [1] cluster has begun a work to identify a core set of terms
and to extract their definitions from relevant standards for maintenance terminology given in table 1.
Table 1
Standards used for terminological analysis
535 terms have been listed, 68 terms among them have been selected in order to compare their definitions in the
different standards. Comments can be made:
- Among the selected core terms, some are specific to maintenance or to different maintenance sub-domains
and other terms are more general to engineering,
- There are commonalities, with some definitions more precise in one standard, and also sometimes
differences in the meanings of the same term.
A process needs to be defined and implemented to homogenize these definitions, beginning with the terms
common to different engineering domains and following with the terms specific to sub-domains with a context
dependent semantics.
3. Analysis of some differences between terminology
It is important to analyze these differences also for operational reasons in the projects. For instance, the
UPTIME [3] project has used a terminology from IEC 60812 [4] and they are some discrepancies with the
terminology defined in EN 13306 [5], which is pushed by EFNMS, European Federation of National Maintenance
Societies [6], as a common terminology.
We will focus here on a few terms and their definitions either specific or not of the maintenance domain.
Non-specific terms are terms which are used in other engineering and manufacturing domains; the possible
issues need to be addressed because advanced maintenance processes, as predictive maintenance, use data from
various data bases as engineering, manufacturing, production, warehouse, even planning and cost data. Table 2
gives an extract for 4 terms of the analysis carried out for 68 terms.
Table 2
Extract of the definitions of terms from various maintenance standards with some first comments
(Work In Progress to be completed by other sources of definitions)
These definitions show commonalities often due to convergence between two versions of the standards but
also differences in the meanings. We will come back in the next chapter on the term system for instance.
We note also that expressions like "down state", "up state", "degraded state" are parts of the terminology
without a definition of what is the generic term “state”.
At this stage, we make the following questions:
- How to clarify the possible dissensus between these definitions?
- How to check the definitions of terms non-specific to maintenance?
- How to find the definition of a generic term when not defined in the standard?
This task of terminology comparisons between reference standards is necessary as a first step to understand the
semantics of a domain and to define a common terminology. It can be also a long and tedious activity; dispatching
of the work is necessary between people sharing the same basic framework common to all the engineering
lifecycle from design, where models are used to predict failures, to maintenance and even dismantling where
historical data are needed for a proper recycling of parts or disposal of the waste.
Thus, in parallel to solving dissensus between experts of a specific domain, we think it will be helpful to build a
necessary and sufficient framework with definitions and formalization of the common terms to the engineering
domain. As system engineering is more and more deployed in industry to master the growing complexity of
systems and as it is a common approach to all the domains, whatever the type of system, we think we have to focus
on the basic terminology of system engineering.
4. System engineering as a common framework for interoperability of data
System Engineering, with digitalization of engineering activities, is evolving to Model based system
engineering [7] in a context of shift from document-based processes to data and model-based processes.
We have noted some issues in the definitions of the term “system” in the previously analyzed maintenance
terminology standards.
In order to progress on a conceptual basis as solid as needed, we propose to remind some of the formal
definitions given by Mario Bunge in his works on the semantics and the ontology of systems [8], [9], [10] and [11].
Bunge’s ontology has also raised interest to structure information systems [12], [13]. These works deserve
more careful analysis, which cannot be detailed here.
To give what we consider as the gist of the Bunge’s ontology, we list the basics of this ontology:
- The world is made of systems, which are diverse,
- A system is an object, which is made of interacting parts or sub-systems, and which is in interaction with
its environment,
- There are concrete systems, natural or artificial ones; a simple machine is an example of an artificial
concrete system,
- There are also abstract systems, for instance Newton’s theory,
- Concrete systems are known through their physical properties of interest, and these properties are always
changing,
- There are different types of properties, for instance essential properties, which are linked together by a
law, and emergent properties when a system has properties which are not possessed by its sub-systems;
concrete systems have physical properties and abstract systems have formal properties,
- Another important notion is the notion of state, a space of properties values,
- An event can be defined as a change in a properties’ space. See [10], [11].
Patrice Micouin [6] found in Bunge’s ontology the strong conceptual framework he needed to propose a
system engineering methodology where requirements are based on properties. As a requirement is, by definition,
verifiable, it can be formalized in a logical sentence as a constraint on a property. This methodology called
“Property Based Requirement Methodology” is industrially deployed for the design of helicopters systems and
other aerospace systems.
We can see the importance of properties and of formal structures to represent properties, constraints, events
and knowledge in a digital ecosystem.
Properties of systems are represented as data and documents in information system: data sheet, databases,
functional drawings, digital mock-ups thanks to symbolic systems, more or less standardized and common to a
given discipline, used to make the link between the real world and its representation and to handover knowledge on
the system.
UPTIME [3] is a platform with components including edge computing, analyze of data thanks to artificial
intelligence techniques. The UPTIME platform can be plugged to a sensors and information environment of
existing production systems. The whole can be considered as a Cyber-Physical-System, which is in interaction
with a natural and artificial environment, has concrete parts and abstract parts. Generally speaking, the latter ones,
take more and more importance with integration of software, coupling of information systems and technologies of
digital twins and of artificial intelligence. From the experience of UPTIME, we do think that the framework of
system engineering conceptually supported by Bunge’s ontology fits with the concerns of predictive maintenance
to follow changes of states, that means of the values of critical properties of interest or in the computing of
historical data, to improve predictions on the behavior of a production system and to take the right economical and
safety decisions for maintenance.
5. Conclusion
Standards are a source of terms with definitions to be analyzed and standardized before their formalization and
their translation in a computing language. A shared framework will help the stakeholders from different
disciplines and with different interests to cooperate consistently on a common system. System engineering
principles, methods and tools seem to us the best candidate to build this shared framework.
Besides this shared ontological basis, ontologically consistent modules shall be edited by discipline experts. A
further work shall address the governance of this set of modules and experiment the benefit of advanced
technological standards to use a set of periodically updated ontological modules for contextualized use cases.
Maintenance, responsible for the highest “Up state” of a system, could be a prime activity to co-develop,
complete, deploy and benefit of such a framework.
6. Acknowledgements
This research has been partially supported by the project “UPTIME – Unified PredicTIve MaintEnance
system” (Grant Agreement n° 768634) (https://www.uptime-h2020.eu/) funded by the European
Commission.
7. References
[1] FORESEE cluster web site: http://foresee-cluster.eu/
[2] IOF web site: https://www.industrialontologies.org/welcome-to-the-iof/
[3] UPTIME web site: https://www.uptime-h2020.eu
[4] IEC 60812:2018, Failure modes and effects analysis (FMEA and FMECA)
[5] EN 13306 : 2010, http://irma-award.ir/wp-content/uploads/2017/08/BS-EN-13306-2010.pdf
[6] EFNMS: https://www.efnms.eu/
[7] Patrice MICOUIN. Model Based System Engineering. Wiley. May 2013
[8] Mario BUNGE. Treatise on Basic Philosophy. 1: Semantics I: Sense and Reference. D. Reidel, Cop., 1rst
edition, 1974.
[9] Mario BUNGE. Treatise on Basic Philosophy. 2: Semantics II: Interpretation and truth. D. Reidel, Cop.,
1rst edition, 1974.
[10] Mario BUNGE. Treatise on Basic Philosophy. 3: Ontology I: The Furniture of the World. D. Reidel, Cop.,
1rst edition, 1977.
[11] Mario BUNGE. Treatise on Basic Philosophy. 4: Ontology II: A world of systems. D. Reidel, Cop., 1rst
edition, 1979.
[12] Joerg EVERMANN. A UML and OWL Description of Bunge’s Upper-Level Ontology Model, Software
and Systems Modeling, April 2009, Volume 8, Issue 2, pp 235-249, Springer.
[13] Yair WAND and Ron WEBER. Toward the deep structure of an information system, Information systems
journal, July 1995