Introduction

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 offer 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 [1,2,3,4,5]. To the best of our knowledge, only [5] proposes, and has openly available, a mid-level ontology for system health monitoring, the Context Ontology for Industry 4.0 (COInd4). COInd4 represents the elements of a real factory, such as machines, processes and sensors (reusing the well-known SOSA/SSN ontology [6]), but by mostly focusing on modeling the context (i.e., the situation) of operation of these elements. Sensor failure, which happens very often in system monitoring (e.g., [3]), is not captured by COInd4. Additionally, COInd4 considers only sensor results, while in the diagnostic process, calculated values from simultaneous outputs from multiple sensors may also be required (e.g., [1,3]).

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 offer 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 [7]). SHM is publicly available1 with namespace http://www.semanticweb.org/SHM# but for short in the following we use the prefix shm instead.

In the next section, we present the SHM ontology which we evaluate against a set of competency questions collected from domain experts.

Ontology Development Process

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 different 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 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 Model 4 , with prefix sem. For company data, the GoodRelations ontology 5 is reused with prefix gr. Finally, for the geometries of the systems and system components, the GeoSPARQL ontology 6 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 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 affect 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, differently 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.

Conclusion and Future Work

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 different application areas and its practical scalability to handle large-scale systems and streaming data.