Sensors, inside internet-connected devices, analyse the environment and monitor possible unwanted behaviour or the malfunctioning of the system. Current risk analysis tools, such as Fault Tree Analysis (FTA) and Failure Mode and Effect Analysis (FMEA), provide prior information on these faults together expert-driven insights of the system. Many people are involved in this risk analyses process, resulting in disambiguations and incompleteness. Ontologies could resolve this issue by providing a uniform structure for the failures and their causes. However, domain experts are not always ontology experts, resulting in a lot of human effort to keep the ontologies up to date. In this paper, automated mappings from the FMEA data to a domain-specific ontology and the generation of rules from a constructed FTA were researched to annotate and reason on sensor observations semantically and provide some first steps towards automated, expert-driven fault detection. The approach is demonstrated with a use case to investigate the possible failures and causes of reduced passenger comfort levels inside a train.
Sensor monitoring systems are transforming the industry, with game-changing
applications in, e.g., transportation [
Sense the smoke level in the environment RCA will continue to grow as more relevant data is generated and tools become widely accessible that can handle data from diverse operating environments.
However, domain-specific knowledge needs to be leveraged to clearly define
the unwanted behaviour and its causes inside these tools as sensor, or system
behaviour in general, varies wildly between application domains. This knowledge
is often provided by domain experts by using risk analysis, which define all
the possible failures and their (observable) effects on the system. Failure Mode
and Effects Analysis (FMEA) [
Constructing these FMEA and FTA documents is a time-consuming process
when applied thoroughly. A large number of experts are involved, who each have
expertise in other parts of the system and interpret different parts of the risk
analysis differently. Ambiguities, inconsistencies and duplicates are, therefore,
quite common. These disagreements reduce the advantages of these risk analysis
and make it difficult for non-experts to interpret and use these documents.
Sharing, however, a common understanding about the structure of the system and
contextual knowledge amongst the experts could help in separating the domain
knowledge from the operational knowledge about the (mal)functioning of the
system. Ontologies and accompanying inference rules have proven their worth in
providing a common knowledge representation about a domain by defining
common concepts and generalizable rules [
In contrast, the effort to enable domain experts to generate ontologies and rules based on the domain knowledge captured in the FMEA and FTA documents will lower the barrier to use them in existing data analysis methodologies. The generated ontologies and rules themselves can be used to annotate and reason upon incoming sensor observations, to eventually provide some essential tools for preliminary semantic-based AD and RCA.
In this paper, we propose an approach to automatically generate the required ontologies and inference rules from the aforementioned risk analysis outcomes. The entries from the FMEA table will be used to create a domain-specific ontology. The fault trees will be used to derive rules to clarify if a particular sensor observation leads to failure or not. The automation of this approach reduces the need for the involvement of ontology and rule experts in the risk analysis process while enabling maintainable, semantic-based AD and RCA. As such, the domain experts can focus on their primary task, i.e., applying their domain knowledge to accurately capture the unwanted behaviour of a system and its causes.
The remainder of the paper is structured as follows. Section 2 situates our approach with respect to the related work. The designed approach is discussed in detail in Section 3, while Section 4 details the application of the approach on a real-life use case, i.e., investigating the possible failures and causes of reduced passenger comfort levels inside a train. Section 5 highlights the most important accomplishments and discusses the directions for future work. 2
As previously mentioned, ontology-based risk analysis methods have been
proposed. Dittmann et al. [
FTA has the advantage to be a more rigorous approach due to the
step-bystep reasoning. Contrary to FMEA, FTA is a graphical method and already
identifies the interrelations between concepts. As a result, FTA is more interpretable
than FMEA as the latter forces the analyst to decompose the system [
While an ontology can capture the various concepts occurring within a
domain and their intricate relationships, additional expressivity is required to
derive that a fault has occurred out of the combination of various system
observations. Rule languages, such as RuleML [
It can be concluded that currently, no approaches exist that allow system experts to use their traditional risk analysis methodologies, i.e. FMEA tables and FTA trees, while still providing methods to automatically extract unambiguous and consistent ontologies and rules from them in a user-friendly manner. 3
User-friendly approach to extract knowledge from risk
analyses
Tools which detect and analyse the unwanted behaviour directly from the
sensor observations, such as AD and RCA, can use the expert knowledge as
input, preferably in a semantic format to operate automatically. Inferring the
failures based on the incoming sensor observations, in combination with a
domainspecific ontology, enable the detection of irregularities and the derivation of their
causes. The generated ontologies and inference rules are the building blocks to
determine this unwanted behaviour and can be incorporated in a
knowledgebased monitoring system to identify anomalies and their causes continuously. For
example, they can be integrated into MASSIF, a data-driven platform for the
semantic annotation of and reasoning on Internet-connected data, allowing
complex decision-making processing [
To generate these rules and ontologies in a user-friendly manner, we propose an approach to automatically extract them from FMEA and FTA documents and trees, as visualised in Figure 3.
The first part of this automation approach uses declarative mapping rules to map FMEA documents on domain-specific ontologies describing the components and their associated anomalies, causes and system effects. Second, predefined translation scripts are used to extract the inferences rules from the FTA trees. It is important to state that both the mapping rules and scripts are generic and can be re-used for every new FMEA table and FTA tree. Only when the structure or template of the documents changes, additional mappings or changes to the scripts will have to be provided. Different methodologies to easily provide these changes with a minimum amount of human effort or knowledge about ontologies and inference rules are also provided. Both are part of the semantic enhancement visualises in Figure 2.
To ease the explanation of the different steps, a running example based on a smart fire detector will be used in the next sections. The end goal is to semantically map the observations from this fire detector to possible failures and give further tools the possibility to derive possible causes. A part of the FMEA is visualised in Figure 1 (a) and it describes the possible failures of the available smoke sensor. A false alarm (failure effect) could be generated when dust accumulates in the device (failure cause), as it hinders the sensor from observing the environment correctly. The data inside the FMEA tables can be used to define a domain-specific ontology, describing the links between several components of the system and their
+
RML rules
Mapping generator possible failures and related causes. The automated process transforming these tables to an ontology is visualised in the top part of Figure 3. The FMEA tables, represented as CSV files, will be used for the mapper as input. The mapper itself will use rules to convert the data inside the table to ontology concepts with predefined links between them. Both the description of the rules and the links between the concepts in the FMEA tables will be explained in this section. Folio ontology
Before we can specify the methodology to extract knowledge from FMEA &
FTA documents for a specific domain ontology, a definition of the common
concepts within the risk analysis domain should be given. Therefore, we developed
an ontology, called Folio1, which captures all application-independent concepts
that occur within FMEA, FTA and anomaly detection methods. It is based
on the aforementioned ontologies constructed by Zhou, et al. [
The Anomaly class defined inside Figure 4 and the directly connected classes include all the possible anomaly information. These classes were adapted to ensure applicability in a context of detecting anomalies for Internet-connected devices and can determine the irregularities in streaming data. The Semantic 1 Folio ontology: https://github.com/IBCNServices/Folio-Ontology/blob/master/Folio.owl y t li a trsc ii C a h folio:Criticality y r o g e t a C s a h folio:Category folio:Anomaly tc e ffsE a h folio:Effect hasEffect
A s i folio:FailureEffect n o i ttc e e D s a h folio:DetectionMethod A s i folio:LocalEffect hasLowerEffect hasNextEffect
isA hasLowerEffect folio:IntermediateEffect
hasNextEffect A s i isLocalEffect isInterEffect folio:FailureCause
A s i e s u a C s a h folio:Cause
A s i External component Subclass relation Specified relation n i a m o D s a h folio:ConsequenceDomain sosa:result t l u s e R s a h : a s o s sosa:Observation isA sosa:makeObservation sosa:Sensor sosa:Observes hasEffect
folio:FailureMode ssn:hasSubSystem sosa:ObservableProperty happenedAt ssn:System
hasCause
Sensor Network (SSN) ontology2 [
The FMEA concepts from Zhou, et al. were extended and related to the anomaly class inside the Folio ontology. The FailureEffect and FailureCause classes are subclasses of the anomaly Effect and Cause classes.
Relations between causes and effects are needed to describe the corresponding connections between multiple components. A FailureCause defines a concept with no further hasNextEffect relations. An IntermediateEffect concept will describe the influence of an intermediate component that is affected by, but not causing, the detected problem. The whole detection flow can have multiple Intermediate Effects. The LocalEffect refers to the first detected effect on the system. A LocalEffect will mostly be related to a faulty sensor observation itself, describing the current state of the device or system component. For the fire detector example, the accumulation of the dust will be defined as a FailureCause because it can be verified as an end effect with no further hasNextEffect relations. The malfunctioning of the sensors are IntermediateEffects, 2 SSN ontology: https://www.w3.org/TR/vocab-ssn/ and they could even have multiple causes. A LocalEffect could be a value too high observation, indicating something is wrong with the system.
Domain knowledge transformation
The previously described upper ontology Folio can now be used to form a more domain-specific ontology, using the data from the FMEA tables. As such, anomaly knowledge can be extracted from the FMEA itself, and the causes of these anomalies can be derived by following the created semantic links. The mapping approach from these table entries to Folio concepts is visualised in the top part of Figure 3 and consists of three different steps. First, the tables itself must be transformed into a computer-readable format to process the information. Second, rules must be generated to map the column and header information from the FMEA table to existing concepts inside the upper ontology. At last a mapping procedure is required to transform all the rows inside the formatted table to domain-specific concepts, eventually creating the domain-specific ontology.
More specific, FMEA is usually performed using a spreadsheet program,
transformable to CSV document used for further analysis. The different
possible elements of each record in the FMEA are fixed and defined by the column
headers of the provided FMEA templates. More concrete, every FMEA table
defines minimal the failures, their effects and their causes of a system. To enable
the mapping of the FMEA on the Folio ontology, these column headers should
be mapped on ontological concepts. A mapping language was used to realise
this, which enables the declarative definition of how to generate RDF from
existing data sources through a set of rules. Our approach uses the RML mapping
language [
We defined the RML rules following the guidelines of the Folio ontology
via the RMLEditor [
This approach is preferred because mapping languages provide a reusable
solution, while custom software and mapping scripts are limited to a specific
use case or implementation [
Rule generation approach While the previous part relates the domain-specific information of failures and causes together, faulty sensor observations must be mapped to the correct failures before a semantic-based monitoring system, such as the one describe in Figure 2 can be operational. Rules are used for specifying the irregularities in the data through defining patterns or operational ranges. For example, a smoke detector can be defined as faulty, when it measures impossibly high values of dust accumulations. This requires experts to define the normal value ranges for these sensors adequately. The Folio ontology and the previously explained FMEA mapping approach already allow defining the observations and their resulting values made by sensors. This section describes how rules can be extracted from the FTA trees to link these observations to possible faults that occur, by using the process visualised at the bottom of Figure 3. Similar to the FMEA mapping approach, three different steps can be defined. First, the trees themselves must be transformed into a computer-readable format to process the rules. Second, tree-agnostic knowledge must be mapped to specific rule concepts to perform the translation between the tree representations and the rule definitions. At last a mapping procedure is required to transform all the information inside the formatted trees to domain-specific rules.
Decision Fault Trees
While original fault trees describe the relationship between the components of the system, they usually do not allow to differentiate the observations from their possible failures. In the case of the fire detector example visualised in Figure 1 (b), the link between the sensor observations and all the possible failures shows the interaction of the different system components but does not capture the difference between the accumulation of dust or, for example, a broken sensor.
A fault tree created from the FTA restricts the analysis to the relations between the components inside the system solely. Therefore, a combination of a decision tree, which is capable of modelling the decision from observations to failure with the possible consequences, together with the general FTA tree, is used here. This so-called decision fault tree (DFT) provides tests on the intermediate edges of the tree, visualising the basic rules for further analysis. Figure 5 gives an example of such a decision tree, related to our fire detector example. When a certain smoke observation has a value greater than 50 ppm, the observation can be classified as a ValuesTooHigh failure.
Smoke Observation
Value>50 Value<=50
ValuesTooHigh
Normal behaviour
A user interface was designed to build such DFTs, as shown further in Figure 8. In this editor, descriptions of the observation and failure nodes can be given. These different node concepts should align with the concepts defined in the FMEA. Tests describing the relations between these observations and failures can be added or adapted. Several representations are possible for such DFTs. The user-interface outputs JSON file to describe the nodes and the rule-specific edges.
Domain-specific decisions The constructed DFTs can now be used as input to define the domain-specific decisions, relating the observations to previously defined failures in the FMEA procedure. To translate the decision inside the tree to rules, a rule generator script was designed in Python5 to transform the JSON representation into SWRL rules. In a first step, the decision and nodes are gathered from the DFT inside a JSON format. Second, RDF syntax rule definitions are used as mock-ups for the SWRL rules. These definitions specify all the basic boolean operations, as well as the logical operators (<; ; ==; ; >). The JSON DFTs are then provided as input to these definitions, resulting finally in specific SWRL rules. These SWRL rules can be attached to the FMEA RDF document or can be saved separately. To give an example, the generated SWRL rule specifying a ValuesTooHigh failure in the fire detector example of Figure 5 looks as follows: 5 Script: https://github.com/IBCNServices/Folio-Ontology/blob/master/swrl_builder.py SmokeObservation(?o) ^ hasResult(?o, ?result) ^ hasValue(?result, ?value) ^ swrlb:greaterThan(?value, 50)
-> ValuesTooHigh(?o) This rule describes the inference of a ValuesTooHigh failure when an observation is a SmokeObservation and the result value of this observation is greater than 50.
Similar to the FMEA mapping procedure, the python mock-ups are defined once and can operate on all generated DFTs. Changing the information inside or adding new information regarding risks and failures to the DFTS do not affect the rule generation process. Only if the DFT components changes, e.g. If new functional operators are added, a new mock-up must be defined. 4
Use case: Measuring Train Passenger Comfort
The growing requirements for quality of service put new challenges on the
operation and development of trains and railway tracks. Therefore, research on the
passenger comfort levels has reached high interest in the last decade [
The company installing these train monitoring units, i.e. Televic Rail, performed risk analyses. The resulting FMEA table, visualised in Figure 7, shows the possible failures of a disallowed comfort level that result in the effect of multiple falsely generated warnings for the train driver. Two possibilities are a broken or malfunctioning sensor. The FMEA table shows that the cause of the latter is varying outdoor temperatures while degradation causes the broken sensor. Replacing or recalibrating it could solve these issues.
Component
Function
FMEA_temp Failure Mode Failure Effect
Failure Cause Accelerometer Sensor Measures changes in
gravitational acceleration
A DFT was also modelled by Televic in the designed web interface, as shown in Figure 8. This tree describes the relationship between the temperature observations of the accelerometer unit and the humidity observations of the gyroscope sensor unit with their possible failure modes. A ValuesTooHigh failure can occur when the temperature of the accelerometer has a value higher than 125 degrees Celsius. The value range is this high because the accelerometer module operates on the wheel axles and these components are influenced by much frictional heat. A second failure can be derived when the temperature value is lower or equal than minus 40 degrees Celsius. We will refer to to same ValuesTooHigh failure for visualization purposes. At last, the same ValuesTooHigh failure can be used to indicate the humidity of the gyroscope has a value higher than 85%. All other observations are classified as normal in this simple use case.
The corresponding JSON file of the DFT and the CSV file of the table can be given as input to the mapping engine. The RML rules are here already predefined (same rules as defined in the fire detector example) and map the specific input fields to an RDF train-specific ontology. A schematic overview of the generated ontology is given in Figure 9 and visualises the major concepts of Figure 7. The inferred rules of the DFT, given in Figure 8, are visualised in Listing 1.1. This listing describes three SWRL rules corresponding to the paths from the sensor observations to the single failure mode. When an accelerometer temperature observation reaches the reasoning engine, and its value is greater than to 125 degrees Celsius, the observation will be classified as a ValuesTooHigh failure and further actions can be taken.
HumidityObservation (?o) ^ hasResult (?o, ? result ) ^ swrlb : greaterThan (? Value , 0.85) ^ hasValue (? result , ? Value ) -> ValuesTooHigh (?o) hasResult (?o, ? result ) ^ swrlb : greaterThan (? Value , 50) ^ hasValue (? result , ? Value ) ^ TemperatureObservation (?o) ^ swrlb : greaterThan (? Value , 125) -> ValuesTooHigh (?o) swrlb : lessThanOrEqual (? Value , -40) ^ hasResult (?o, ? result ) ^ hasValue (? result , ? Value ) ^ TemperatureObservation (?o) ^ swrlb : lessThanOrEqual (? Value , 50) -> ValuesTooHigh (?o)
Listing 1.1: SWRL rules derived from the DFT in Figure 8
In this paper, research is proposed to enable the automatic knowledge extraction out of risk analyses into domain-specific ontologies and accompanying inference rules. Mappings were provided to incorporate the knowledge inside FMEA documents into a domain-specific ontology. An upper ontology was used to relate the main concepts, making the methods operational for several, different applications. Inference rules were extracted from DFTs, which were able to express the link between sensor observations and defined failures. Both methods allow system experts to use the risk analysis methodologies and tools they are used too to build a domain-specific ontology with accompanying rules, without the additional need for ontology experts. These ontologies and accompanying rules ensure that a common vocabulary and consistency check is maintained and can be used to enable on the fly detection of anomalies and their causes through semantic reasoning. It enables the system experts to focus on the risk analysis task, instead of on a knowledge modelling task for which they do not have the adequate ontology design expertise. Future research can now use the designed ontologies, together with accompanying rules to derive or reason on the possible causes inferred from the failures. Additionally, the DFT editor itself can be extended with consistency checks to ensure improved rule generation. Acknowledgment: This research is part of the imec ICON project Dyversify, co-funded by imec, VLAIO, Renson Ventilation NV, Televic Rail & Cumul.io.