Early fault diagnosis plays a crucial role in maintaining the health and safe operation of equipment. However, only a select few of the current diagnostic tools are of high genericity, reliability and can perform eficiently on-line at the same time. Furthermore, there is only limited research identifying both system faults and sensor faults simultaneously. Semantic-based technologies can ofer a holistic view of monitored systems and their operation, providing in this way better insights and enhancing decision support. Towards this goal, in this research work, we present the light-weight mid-level System Health Monitoring (SHM) ontology. The SHM ontology models the health state of a system at each time instance based on sensor outputs and calculated values from these outputs, along with their reliability rates. The requirements specification for the development of the SHM ontology has been based on domain experts' competency questions (from two diferent application areas), and the ontology has been evaluated against these questions.
With the rapid development of industry, early fault diagnosis plays a crucial role in maintaining the health and safe operation of equipment. Semantic-based fault diagnosis approaches can ofer a holistic view of monitored systems and their operation, enhancing their capability to maximise their lifetime potential. Semantic technologies allow seamless integration of the structural (static) and operating (streaming) data of a system and its ancillary systems (e.g., sensors) along with the formal representation of expert’s knowledge in a human and machine processible form. This way, neuro-symbolic technologies combining neural networks and symbolic AI approaches (e.g., ontologies and logics) can be applied to extract useful insights with regard to the health state of the system enabling robust early diagnosis and decision support.
In the last few years numerous studies have appeared in the literature about semantic-based
health monitoring; prominent examples include [
In this short paper, we present the System Health Monitoring (SHM) ontology. SHM is a
lightweight, mid-level ontology for the representation of the health condition of an operating
system at each time instance of its operation. For the reliable diagnosis of the monitored system
we also represent formally the reliability of the monitoring sensors at each time instance, and,
therefore, the reliability of the calculated results from the sensor outputs and the reliability
of the resulting diagnosis. To ofer a 360 ∘ view of the monitored system, we also model static
knowledge about the monitored system (e.g., manufacturing company, production date, location
of system components etc.) and the sensors used for its health monitoring. In this way, utilizing
a query/question answering system, the end user can, for instance, ask about the health state
of a system at each time instance and the reliability of this result, about mitigation actions
to prevent forthcoming failure, or about the reliability of the monitoring sensors at some
time instance. In this way, the end user can obtain a deeper understanding of the monitored
system and its operation. The OWL expressivity of SHM is OWL 2 EL, hence sound and
complete reasoning can be performed in PTIME with respect to the size of the data. Also, it
can be supported by well-known reasoners (e.g., HermiT [
In the next section, we present the SHM ontology which we evaluate against a set of competency questions collected from domain experts.
For the development of the ontology we followed standard approaches suggested in the literature (e.g., [8]), which start with the specification of requirements to define the purpose and the scope of the ontology. For this purpose, domain experts from two diferent application areas of system health monitoring (structural health monitoring and fuel cell system monitoring) provided us with a set of competency questions. After identifying and reusing relevant ontologies from the literature, we proceeded with formalising the required knowledge. Finally, after populating the ontology with sample data from a real-world use case scenario (fuel cell monitoring), we performed consistency checking and we queried the resulting knowledge base using the provided competency questions.
Specification of Requirements. Thirty-one competency questions were collected from domain experts in system health monitoring. The collected questions were roughly about: i) sensor outputs, which can be supported solely by SOSA/SSN (e.g., “What are the mean, min and max values of strain measured by sensor during a certain period?”), ii) the health condition of 1https://github.com/eleniTsalapati/System-Health-Monitoring/blob/main/SHM.owl the system in relation to its static (e.g., production date, location of components) and non-static (e.g., the value of a parameter) properties, iii) sensor reliability, and iv) correlations among parameters (e.g., “What is the correlation between parameters and ?”, “When has the correlation between and changed?”). From this set of questions, we kept only the ones that an ontological knowledge base could be utilized for their answering, i.e., questions of type iv) were filtered out as they cannot be addressed by standard logic-based query answering tools. Due to space limitations, we present in Table 1 only eight representative questions for cases ii) and iii).
Ontology Reuse. In line with the Linked Data principles [9], SHM reuses classes and properties from well known external ontologies. The excerpts of the external ontologies that we reused in SHM are illustrated in Figure 1i). However, if needed, SHM can be extended with more knowledge from these ontologies. For the representation of knowledge regarding sensors and their outputs, SOSA/SSN constructs2 are reused with prefixes sosa, ssn, respectively. For units and values, we reused the Ontology of units of Measure3, with prefix om. For events and actors (sentients or objects) participating actively or passively in the events we use The Simple Event Model4, with prefix sem. For company data, the GoodRelations ontology5 is reused with prefix gr. Finally, for the geometries of the systems and system components, the GeoSPARQL ontology6 is reused with prefix geo.
The System Health Monitoring Ontology. The SHM ontology is illustrated graphically in Figure 1ii). Two are the core classes of SHM: shm:System and shm:State. The shm:System class is subclass of ssn:System of the SSN ontology. According to SSN, an ssn:System “is a unit of abstraction for pieces of infrastructure that implement sosa:Procedures”. shm:System is subclass of gr:ProductOrService, hence it inherits its properties, and in particular in SHM, it is further specified with the object property gr:hasManufacturer (with range gr:BusinessEntity) and the data property gr:hasName. Additionally, an shm:System can have a shm:productionYear. Information about the manufacturing company and production date allows end-users to identify potential reliable or unreliable manufacturing companies, or correlate faulty systems with specific production years. Finally, shm:System is a subclass of geo:Feature, hence it inherits the property geo:hasGeometry (with range geo:Geometry). The geometry data of the system/system components can be used to answer questions of the form “What is located here?”, or “Where is the sensor monitoring the temperature located?”.
Subclasses of the shm:System class are the shm:MonitoredSystem class and the shm:HealthMonitoringSensor class. At each time instance of its operation, an shm:MonitoredSystem is in some shm:State. An shm:MonitoredSystem is a system that is being monitored by at least one shm:HealthMonitoringSensor and it is composed of 2http://www.w3.org/ns/sosa/, http://www.w3.org/ns/ssn/ 3http://www.ontology-of-units-of-measure.org/resource/om-2 4https://semanticweb.cs.vu.nl/2009/11/sem/ 5http://purl.org/goodrelations/v1# 6http://www.opengis.net/ont/geosparql# at least one shm:SystemComponent, which can act as a platform to host a sensor (i.e., it is a subclass of the class sosa:Platform). The shm:HealthMonitoringSensor class is also a subclass of sosa:Sensor. Additionally, to capture the potential failure of the sensors during their operation, each shm:HealthMonitoringSensor is related to an shm:SensorReliability, which is defined by an shm:reliabilityMeasure (with range xsd:decimal) and a time instance (through the data property shm:atTime with range xsd:dateTime).
The definition of the term shm:State is borrowed from AI Planning: an shm:State is a representation of the state of the world. As in AI Planning, each shm:State may have a previous (shm:previous) or a next (shm:next) shm:State, while the transition from one shm:State to a next may involve an shm:Event or an shm:Action. Each shm:State is described by a single time instance and by a set of observation results (i.e., instances of the class shm:ObservationResult) describing the state of the sensors and of the monitored system at this time instance. An shm:ObservationResult can be either an shm:SensorOutput (which is a subclass of sosa:Result) or a result calculated from the sensor outputs, i.e., an shm:CalculatedResult, that aids the diagnosing process. Also, the class shm:ObservationResult is subclass of om:Measurement, hence, it inherits the property om:hasNumericalValue and it is domain of the object property om:hasUnit. As the Ontology of units of Measure does not define the range of om:hasNumericalValue, in SHM is defined as xsd:decimal, to keep the nice computational properties of OWL 2 EL. Also, the potential unreliability of a sosa:Sensor will afect the reliability of the relevant shm:ObservationResult. This is expressed with the data property shm:resultTruthValue with rdfs:range xsd:decimal.
The shm:HealthMode describes the health condition of a shm:System at each shm:State and it is determined by the observation results. Hence, the potential unreliability of the observation results is propagated to the shm:HealthMode. This is expressed with the datatype property shm:modeTruthValue with rdfs:range xsd:decimal. An shm:MitigatingAction (subclass of shm:Action) may prevent the shm:System from failure.
For the reliability of the diagnostic process it is important to know which sensor outputs are involved in the calculation of each parameter. This is modelled with the object property shm:isCalculatedFrom which correlates each shm:CalculatedResult with all relevant shm:SensorOutputs (notice that, diferently from SOSA/SSN, a calculated result may involve outputs of multiple sensors). Also, the parameter (e.g., relative humidity) that an shm:CalculatedResult expresses is modelled with the property shm:calculatedProperty with range shm:CalculatedProperty (subclass of sosa:Property) and the entity whose property is being calculated is the shm:FeatureOfInterest (subclass of sosa:FeatureOfInterest).
Evaluation In line with the literature (e.g., [10, 11], throughout the ontology development process we performed satisfiability checking using Hermit. We, also, populated the ontology with real monitoring sample data and, then, tested the consistency of the resulting knowledge base. To check the ontology with respect to completeness, we translated the competency questions into SPARQL queries and we verified the results manually. Due to space limitations, next, we provide the SPARQL queries for only eight of the competency questions. The full set of questions with the corresponding queries and answers is publicly available. 7 Finally, SHM passed the OOPS! [12] test, i.e. no structural (i.e., syntax, formal semantics), functional, or usability pitfalls were detected. 7https://github.com/eleniTsalapati/System-Health-Monitoring
In this research work we presented the lightweight mid-level System Health Monitoring Ontology. Based on requirements from domain experts, the literature and existing ontologies, SHM formalises knowledge about health system monitoring taking into account the potential unreliability of the operating sensors. For future work, we plan to check the applicability of SHM in more use case scenaria from diferent application areas and its practical scalability to handle large-scale systems and streaming data.
This project has received funding from the European Union’s Horizon 2020 research and innovation programme under the Marie Sklodowska-Curie grant agreement No 101032307. Evaluation (ORE-2012), Manchester, UK, July 1st, 2012, volume 858 of CEUR Workshop Proceedings, CEUR-WS.org, 2012. URL: https://ceur-ws.org/Vol-858/ore2012_paper13.pdf. [8] M. Fernández-López, A. Gómez-Pérez, N. Juristo, Methontology: From ontological art towards ontological engineering, in: AAAI 1997, 1997. [9] C. Burleson, M. E. Gutierrez, N. Mihindukulasooriya, Linked data platform best practices and guidelines, https://www.w3.org/TR/ldp-bp/, 2014. [10] E. Tsalapati, J. Tribe, P. A. Goodall, R. I. Young, T. W. Jackson, A. A. West, Enhancing rfid system configuration through semantic modelling, The Knowledge Engineering Review 36 (2021) e11. doi:10.1017/S0269888921000096. [11] M. Fernandez-Lopez, A. Gomez-Perez, N. Juristo, Methontology: from ontological art towards ontological engineering, in: Proceedings of the AAAI97 Spring Symposium, Stanford, USA, 1997, pp. 33–40. [12] M. Poveda-Villalón, A. Gómez-Pérez, M. C. Suárez-Figueroa, Oops! (ontology pitfall scanner!): An on-line tool for ontology evaluation, Int. J. Semant. Web Inf. Syst. 10 (2014) 7–34. doi:10.4018/ijswis.2014040102.