Motivation. Diagnostic systems play an important role in industry since they help to maximise equipment's up-time and minimise its maintenance and operating costs [16]. In the energy sector companies like Siemens often rely on rule-based diagnostics to analyse power generating equipment by, e.g., testing newly deployed electricity generating gas turbines [11], or checking vibration instrumentation [13], performance degradation [14], and faults in operating turbines. For this purpose diagnostic engineers create and use complex diagnostic rule-sets to detect equipment abnormalities. An important class of rules that are commonly used in Siemens are signal processing rules (SPRs) that allow one (i) filter, aggregate, combine, and compare signals1 coming from sensors installed in equipment and (ii) send notification messages when a certain pattern in signals is detected. Authoring SPR based rule-sets is challenging. We now discuss this challenge in details and then present our solution to address them. Challenges with Authoring SPRs. The main challenge for authoring is that SPRs in most modern industrial diagnostic systems including the ones used in Siemens are highly data dependent in the sense that specific characteristic of individual sensors and pieces of equipment are explicitly encoded in SPRs. As the result for a typical turbine diagnostic task engineers have to write from dozens to hundreds of SPRs that involve hundreds of sensor ids, component codes, sensor and threshold values as well as equipment configuration and design data. E.g., a typical Siemens gas turbine has about 2,000 sensors and a typical diagnostic task is to verify that the purging2 has ended; for the main flame component of a given turbine, this task requires around 300 SPRs, most of which are similar in structure but different in equipment specific data values. Thus, there is a need in industry, and in particular in Siemens for a higher level diagnostic rule language that allows to express what the diagnostic task should do rather than how it should do it for specific equipment. Such language should be high level, data independent, while powerful enough to express in a concise way most of typical diagnostic tasks in Siemens. Our Solution. We rely on semantic technologies to address the the above mentioned challenges. In particular we rely on ontologies [1] to define a novel SPR language and on reasoning [3] over ontologies to foster execution and maintenance of diagnostic tasks. In short, an ontology is a formal conceptualisation of the domain of interest that consists of a vocabulary, i.e., names of classes, attributes and binary relations, and axioms over the terms from the vocabulary that, e.g., assign attributes of classes, define relationships between classes, compose classes, class hierarchies, etc. Since ontologies 1 Signals are are time stamped sequences of measurement values. 2 Purging is the process of flushing out liquid fuel nozzles or other parts which may contain undesirable residues.
are specified using a formal logical language such as the W3C standardised ontology
web language OWL 2, one can query ontologies and check their properties using
reasoning that typically corresponds to logical entailment and implemented in many
efficient state-of-the-art reasoning systems such as HermiT [
In order to address the authoring challenge we propose: – an SPR language sigRL that treats signals as first class citizens and allows signals to be processed (filtered, aggregated, combined, and compared) in a high level, declarative, and data independent fashion; – semantic diagnostic programs that combine sigRL rules with diagnostic background knowledge captured using ontologies and allow users to express complex diagnostic tasks in an abstract fashion by exploiting both ontological vocabulary and queries over ontologies to identify relevant information (such as sensor ids and threshold values) about the equipment that should undergo the diagnostics.
Note that we designed sigRL in such a way that, on the one hand, it captures the main signal processing features required by Siemens turbine diagnostic engineers and, on the other hand allows for efficient execution of diagnostic programs. 2
We first illustrate sigRL with an example and then describe our system SemDia. sigRL Diagnostic Language. Consider a purging diagnostic task:
Verify that the purging ended in the main flame component of the turbine T1. Intuitively this task requires to check in the turbine T1 that: (i) the main flame was on for at least 10s and then stopped, (ii) 15s after this, the purging of rotors in the starting-component of T1 started, (iii) 20s after this, the purging stopped. The fact that the purging of a rotor started or ended can be detected by analysing its speed, i.e., by comparing the average speed of its speed sensors with purging thresholds that are specific for individual rotors. The purging diagnostic program in our language sigRL can then consist of an ontology with one axiom: SubClassOf(RotorSensor SpeedSensor). two signal processing expressions and one message rule:
PurgingStart = avg rotorStart : value(>; purgingSpeed);
PurgingStop = avg rotorStart : value(<; nonPurgingSpeed); msg(“Purging over”) = FlameSensor : duration(>; 10s) :
after[15s] PurgingStart : after[20s] PurgingStop
For the complete description of sigRL we refer to our papers [
Signal and Data Layer. On this layer we store all the relevant data: turbine design specifications, historical information about services that were performed over the turbines, previously detected events, and the raw sensor signals. Currently SemDia support PostgresQL, Teradata, as well as Sparksee. Demo attendees will be able to learn how to do diagnostics of Siemens turbines with sigRL diagnostic programs. To this end we prepared a deployment of our SemDia system on data from 50 Siemens power generating turbines, a diagnostic ontology, and a catalogue of 15 diagnostic tasks. The attendees will be able to load preconfigured diagnostic programs, deploy and execute them, author their own diagnostic programs, and try out our provenance computation and program verification services. Acknowledgments This research is supported: EPSRC projects MaSI3, DBOnto, ED3; and the Free University of Bozen-Bolzano project QUEST.