=Paper=
{{Paper
|id=Vol-2213/paper2
|storemode=property
|title=Towards Adaptive Anomaly Detection and Root Cause Analysis by Automated Extraction of Knowledge from Risk Analyses
|pdfUrl=https://ceur-ws.org/Vol-2213/paper2.pdf
|volume=Vol-2213
|authors=Bram Steenwinckel,Pieter Heyvaert,Dieter De Paepe,Olivier Janssens,Sander Vanden Hautte,Anastasia Dimou,Filip De Turck,Sofie Van Hoecke,Femke Ongenae
|dblpUrl=https://dblp.org/rec/conf/semweb/SteenwinckelHPJ18
}}
==Towards Adaptive Anomaly Detection and Root Cause Analysis by Automated Extraction of Knowledge from Risk Analyses==
https://ceur-ws.org/Vol-2213/paper2.pdf
Towards Adaptive Anomaly Detection and Root
Cause Analysis by Automated Extraction of
Knowledge from Risk Analyses
Bram Steenwinckel, Pieter Heyvaert, Dieter De Paepe, Olivier Janssens,
Sander Vanden Hautte, Anastasia Dimou, Filip De Turck, Sofie Van Hoecke,
and Femke Ongenae
Ghent University - imec, IDLab, Ghent, Belgium
bram.steenwinckel@ugent.be
Abstract. Sensors, inside internet-connected devices, analyse the envi-
ronment 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 in-
formation on these faults together expert-driven insights of the system.
Many people are involved in this risk analyses process, resulting in dis-
ambiguations 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 hu-
man 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.
Keywords: Anomaly detection · Root Cause Analysis · Risk Analysis ·
Semantics · Ontology development · Sensor data · IoT
1 Introduction
Sensor monitoring systems are transforming the industry, with game-changing
applications in, e.g., transportation [5] and healthcare [20]. These systems can
yield valuable insights into company's physical assets and the interaction of these
assets with their environment. However, sensors have limited added value with-
out data analysis [22]. More and more, new methodologies are defined to specify
the correct functioning of the system based on these sensor observations. Com-
mon methodologies for observing unwanted system behaviour with this data are
Anomaly Detection (AD) and Root Cause Analysis (RCA). AD is the identifi-
cation process of events or observations, which do not adhere to the expected
pattern or other items inside a dataset [20]. RCA guides a problem solver to
deduce and understand the real causes of the anomalies [19]. Interest in AD &
18 B. Steenwinckel et al.
Alerting Issue
Failure Failure Failure Control
Component Function
Mode Effect Cause Method
Fire detector Detects the fire Unwanted Falsely Broken None
evacuation generate sensor
d alarm
Smoke Sense the Values too Broken Dust Clean
sensor smoke level in high sensor accumulation system Broken Power
Dust
the environment Sensor Failure
(a) (b)
Fig. 1: Example of FMEA (a) and FTA (b)
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) [2] and Fault Tree Analysis (FTA) [8] provide
templates to provide such analyses easily. As shown in Figure 1 (a), FMEA
captures, on multiple levels of the system, the potential failures that can occur
to the components and their underlying causes and effects. FTA analyses the
undesired states of a system using Boolean logic. This combination of low-level
events, leading to system failures, can be visualised using a tree, as exemplified
in Figure 1 (b).
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. Shar-
ing, 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 com-
mon concepts and generalizable rules [23]. However, most system experts are not
familiar with ontology design, which makes these approaches difficult to imple-
ment and maintain. Semantic Web experts are required to constantly improve
and update these ontologies and accompanied rules with new domain-specific
knowledge.
In contrast, the effort to enable domain experts to generate ontologies and
rules based on the domain knowledge captured in the FMEA and FTA docu-
Automated Extraction of Knowledge from Risk Analyses 19
ments 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 ontol-
ogy. 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 Related work
As previously mentioned, ontology-based risk analysis methods have been pro-
posed. Dittmann et al. [7] describes a process to capture the results of a FMEA
in an ontology, instead of in a document and highlighted the (dis)advantages.
Rehman et al. [18] and Zhou et al. [24] designed high-level ontologies to model
the main concepts of a FMEA and their relationships. The first applied it to
model the results of a FMEA in the automotive domain. The second used it
to capture the FMEA of wind turbines and developed a reasoning framework
to perform intelligent fault diagnosis using the designed ontology capturing the
domain-specific concepts. Both papers showed how an ontology could be used
to easily trace the relationships between failures and their corresponding causes,
making it easier to interpret the risk analysis. Ontologies to automatically link
the observations made within a particular system to anomalies or faults that
can occur, have also been proposed [16]. Although high-level concepts have been
defined to model irregularities and link them to system components and effects,
an ontology expert is required to model all the domain-specific anomalies that
can occur and how they link to the sensor observations. None of the proposed
ontologies are publicly available, hindering re-use. Moreover, all the approaches
propose to replace the existing methodologies with a process in which the re-
sults of a FMEA are directly captured in an ontology. This requires extensive
knowledge about ontology design from the system experts as the current FMEA
are performed using standard spreadsheet tools.
FTA has the advantage to be a more rigorous approach due to the step-by-
step reasoning. Contrary to FMEA, FTA is a graphical method and already iden-
20 B. Steenwinckel et al.
tifies the interrelations between concepts. As a result, FTA is more interpretable
than FMEA as the latter forces the analyst to decompose the system [17]. In an
effort to automate the construction of the FTA trees, Venceslau et al. [21] de-
fined an ontology to model the system components and failures and constructed
a technique to generate the FTA tree from the constructed ontology automati-
cally. The use of the ontology solves the issue of inconsistencies and ambiguities
between FTA trees due to the lack of a common knowledge representation and
the automatic generation of the tree ensures human understanding of the result.
However, it again requires ontology design knowledge from the system experts.
While an ontology can capture the various concepts occurring within a do-
main and their intricate relationships, additional expressivity is required to de-
rive that a fault has occurred out of the combination of various system obser-
vations. Rule languages, such as RuleML [3] and SWRL [13] can define infer-
ence rules, which are used inside a semantic reasoner to derive logical conse-
quences. Recently, techniques have been designed to extract SWRL rules from
text using NLP [11] or mine Semantic Web Association Rules from RDF data
(SWARM) [1]. However, there are, to our knowledge, currently no techniques
which allow the automated extraction of rules from risk analyses.
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 sen-
sor observations, such as AD and RCA, can use the expert knowledge as in-
put, preferably in a semantic format to operate automatically. Inferring the fail-
ures based on the incoming sensor observations, in combination with a domain-
specific 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 knowledge-
based 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 com-
plex decision-making processing [4]. When new sensor observations are generated
by the system, MASSIF semantically annotates them using the domain-specific
ontologies. MASSIF then uses a semantic reasoner to process the generated rules
and links defined in the ontologies to determine whether failures are occurring
and what their possible causes are. As such, the sensed data can be combined on
the fly with background knowledge, resulting in enhanced and adaptive context-
aware AD and RCA applications. This full process is visualised in Figure 2. The
next sections will focus mainly on the first part of this approach: the extraction
Automated Extraction of Knowledge from Risk Analyses 21
and combination of sensor data and expert knowledge in the form of FMEA and
FTA.
FMEA/FTA Semantic AD
Enhancement
Sensor data RCA
Fig. 2: Overview of the approach to combine knowledge with sensor data for AD
and RCA
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 seman-
tically 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 accu-
mulates in the device (failure cause), as it hinders the sensor from observing the
environment correctly.
3.1 Ontology mapping approach
The data inside the FMEA tables can be used to define a domain-specific on-
tology, describing the links between several components of the system and their
22 B. Steenwinckel et al.
+
Domain ontology
RMLEditor Folio Ontology (based on Folio)
FMEA tables
RML rules
RML Mapper
Python script
SWRL rules
FTA tree Mapping generator
Fig. 3: Overview of the approach to extract knowledge from risk analyses
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 it-
self 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 con-
cepts 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. [24] and Pardo,
et al.[16]. There are several concepts inside the FMEA template similar in the
anomaly domain. The effects and causes of an anomaly can be related to the
failure causes and effects, while both have detection methods and a degree of
severity. Combining the concepts of both of them enables the derivation of the
possible anomaly causes with the available knowledge inside the FMEA work-
sheets.
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
Automated Extraction of Knowledge from Risk Analyses 23
folio:Anomaly
hasDetection
hasCriticality
hasCategory
hasDomain
hasCause
hasEffect
folio:ConsequenceDomain folio:Criticality folio:Category folio:Effect folio:DetectionMethod folio:Cause
hasEffect
isA
sosa:result
isA
folio:FailureEffect
sosa:hasResult
isA
isA
hasLowerEffect hasLowerEffect
folio:LocalEffect folio:IntermediateEffect folio:FailureCause
isA hasNextEffect hasNextEffect
sosa:Observation
isA
isLocalEffect isInterEffect
isA
sosa:makeObservation
sosa:Sensor folio:FailureMode
hasEffect hasCause
happenedAt External component
ssn:hasSubSystem
ssn:System Subclass relation
sosa:Observes
sosa:ObservableProperty Specified relation
Fig. 4: The Folio ontology.
Sensor Network (SSN) ontology2 [9,14,10] describes sensors and their observa-
tions for a diverse range of devices and is included in this upper ontology. The
SSN architecture includes a lightweight, but self-contained core ontology called
SOSA (Sensor, Observation, Sample, and Actuator) for its elementary classes
and properties. With their different scope and different degrees of axiomatiza-
tion, SSN and SOSA can support a wide range of applications and use cases. By
using SSN & SOSA, the Folio ontology can describe the sensor's observations
that are the basis for analysing the system behaviour. Relationships were defined
in Folio to correlate the SSN classes with possible failures and effects.
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 correspond-
ing connections between multiple components. A FailureCause defines a con-
cept with no further hasNextEffect relations. An IntermediateEffect con-
cept 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 compo-
nent. 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/
24 B. Steenwinckel et al.
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 pos-
sible 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 ex-
isting data sources through a set of rules. Our approach uses the RML mapping
language [6].
We defined the RML rules following the guidelines of the Folio ontology
via the RMLEditor [12], which offers a graphical user interface to aid users in
defining rules. The high levels steps we followed are as follows: (i) a sample of
an FMEA table was loaded in the RMLEditor, (ii) the rules were created by an
ontology expert, (iii) the corresponding RDF triples were generated, (iv) if the
triples are not as expected the rules are updated, and (v) the rules are exported3 .
Afterwards, the RMLMapper4 , a tool to execute RML rules, is used to generate
the ontologies for all FMEA tables. The mappings ensure that for each cell in
the FMEA table, a new class is created in the ontology, which is a subclass of
the class on which the column is mapped according to the rules. For example, if
we consider the 5th cell on the second row of Figure 1 (a), the RMLMapper will
create a new concept DustAccumulation in the ontology, which has as superclass
the FailureCause class.
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 [6]. Another advantage is the adaptive character
of the mapping rules: when making changes in the representation of the data
updating the mapping rules will suffice to incorporate this extra information
3
RML rules: https://github.com/IBCNServices/Folio-Ontology/blob/master/mapping.rml.ttl
4
RMLMapper: https://github.com/RMLio/RML-Mapper
Automated Extraction of Knowledge from Risk Analyses 25
in the domain-ontology. As such, these mappings can be re-used to translate
any FMEA table that is created according to the standard FMEA structure.
Changing the information inside or adding new information regarding risks and
failures to the FMEA documents do not affect the generation of the domain
ontologies at all. Only if the template changes, e.g. If a new column is added or
for instance, the risk analysts switch to a more advanced Failure Mode, Effect
and Criticality Analysis method, new rules must be defined, which can easily be
created by mapping the columns to the Folio classes by using the RMLEditor.
Due to the frequently used FMEA templates, this will not happen often. In our
fire detector example, this means that updating the FMEA documents, by adding
an additional cause for the unwanted evacuation (for instance a broken test
button), does not affect the domain ontology generation process. The outcome
of our mapping approach is a domain ontology in OWL. In our fire detector
example, this ontology will relate the failures of the temperature and smoke
sensors to the general system effects, using the relationships of the upper Folio
ontology.
3.2 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 fail-
ures 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 map-
ping 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.
26 B. Steenwinckel et al.
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.
> 50
Value ValuesTooHigh
Smoke
Observation
Value
< =50 Normal behaviour
Fig. 5: example of a Decision Fault Tree.
A user interface was designed to build such DFTs, as shown further in Fig-
ure 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 fail-
ures 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
Automated Extraction of Knowledge from Risk Analyses 27
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 oper-
ation and development of trains and railway tracks. Therefore, research on the
passenger comfort levels has reached high interest in the last decade [15]. As
shown in Figure 6, train bogies are now equipped with accelerometers and gyro-
scope sensors, able to detect the shocks and damping effect of the train on the
tracks. Multiple sensor observations of different train cars can be combined on
a server to indicate the passenger comfort inside the train. Maintenance alerts
are given to both the train or track staff to resolve the issues.
Fig. 6: Schematic overview of a train.
The company installing these train monitoring units, i.e. Televic Rail, per-
formed 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.
28 B. Steenwinckel et al.
FMEA_temp
Component Function Failure Mode Failure Effect Failure Cause Control Containment
Method Action
Passenger Comfort Unit Detects the level of Comfort False warning Indicating impossible Broken sensor None None
comfort level
Accelerometer Sensor Measures changes in Values too high Broken sensor Degradation of the None Replace Sensor
gravitational acceleration sensor
Malfunctioning sensor Rapid temperature None Calibrate sensor
changes
Gyroscope Sensor Measure the smoke level Values too high Broken sensor Degradation of the None Replace Sensor
sensor
Malfunctioning sensor Rapid temperature None Calibrate sensor
changes
Fig. 7: Train passenger comfort FMEA example
Fig. 8: Train sensors DFT example
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 obser-
vations 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
1
Automated Extraction of Knowledge from Risk Analyses 29
Fig. 9: Ontograf visualisation of the passenger comfort FMEA ontology
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 ) ^
Te mp era tur eO bse rv ati on (? o ) ^
swrlb : greaterThan (? Value , 125)
-> ValuesTooHigh (? o )
swrlb : lessThanOrEqual (? Value , -40) ^
hasResult (? o , ? result ) ^
hasValue (? result , ? Value ) ^
Te mp era tur eO bse rv ati on (? o ) ^
swrlb : lessThanOrEqual (? Value , 50)
-> ValuesTooHigh (? o )
Listing 1.1: SWRL rules derived from the DFT in Figure 8
5 Conclusion and Future work
In this paper, research is proposed to enable the automatic knowledge extraction
out of risk analyses into domain-specific ontologies and accompanying inference
30 B. Steenwinckel et al.
rules. Mappings were provided to incorporate the knowledge inside FMEA doc-
uments into a domain-specific ontology. An upper ontology was used to relate
the main concepts, making the methods operational for several, different appli-
cations. 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 ex-
tended 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.
References
1. Barati, M., et al.: Swarm: approach for mining association rules from semantic web
data. In: Conference on Artificial Intelligence. pp. 30–43. Springer (2016)
2. Ben-Daya, M.: Failure mode and effect analysis. In: Handbook of maintenance
management and engineering, pp. 75–90. Springer (2009)
3. Boley, H., et al.: Design rationale of ruleml: A markup language for semantic web
rules. In: Proceedings on Semantic Web Working. pp. 381–401. CEUR-WS (2001)
4. Bonte, P., et al.: The massif platform: a modular and semantic platform for the
development of flexible iot services. Knowledge and Information Systems (2017)
5. Camossi, E., et al.: Semantic-based Anomalous Pattern Discovery in Moving Ob-
ject Trajectories. CoRR abs/1305.1 (2013)
6. Dimou, A., et al.: Rml: A generic language for integrated rdf mappings of hetero-
geneous data. In: LDOW (2014)
7. Dittmann, L., et al.: Performing fmea using ontologies. In: 18th International Work-
shop on Qualitative Reasoning. Evanston USA. pp. 209–216 (2004)
8. Ericson, C.A.: Fault tree analysis. Hazard analysis techniques for system safety pp.
183–221 (2005)
9. Haller, A., Janowicz, K., Cox, S.J.D., Le Phuoc, D., Taylor, K., Lefrançois, M.:
Semantic Sensor Network Ontology. W3C and OGC Recommendation, W3C &
OGC (Oct 19 2017), https://www.w3.org/TR/vocab-ssn/
10. Haller, A., Janowicz, K., Cox, S.J., LefranÃğois, M., Taylor, K., Le Phuoc, D.,
Lieberman, J., Garcia-Castro, R., Atkinson, R., Stadler, C.: The modular SSN
ontology: A joint W3C and OGC standard specifying the semantics of sensors,
observations, sampling, and actuation. Semantic Web Journal (2018)
11. Hassanpour, S., et al.: Framework for the automatic extraction of rules from online
text. In: Workshop on Rules and Rule Markup Languages. Springer (2011)
Automated Extraction of Knowledge from Risk Analyses 31
12. Heyvaert, P., et al.: Rmleditor: a graph-based mapping editor for linked data map-
pings. In: International Semantic Web Conference. pp. 709–723. Springer (2016)
13. Horrocks, I., et al.: Swrl: A semantic web rule language combining owl and ruleml.
W3C Member submission 21, 79 (2004)
14. Janowicz, K., Haller, A., Cox, S.J., Le Phuoc, D., LefranÃğois,
M.: SOSA: A lightweight ontology for sensors, observations,
samples, and actuators. Journal of Web Semantics (2018).
https://doi.org/https://doi.org/10.1016/j.websem.2018.06.003
15. Karimpanal, T.G., Gadhia, H.M., Sukumar, R., Cabibihan, J.: Sensing discomfort
of standing passengers in public rail transportation systems using a smart phone.
CoRR (2017)
16. Pardo, E., et al.: A framework for anomaly diagnosis in smart homes based on
ontology. Procedia Computer Science 83 (2016)
17. Peeters, J., et al.: Improving failure analysis efficiency by combining fta and fmea
in a recursive manner. Reliability engineering & system safety 172, 36–44 (2018)
18. Rehman, Z., Kifor, C.V.: An ontology to support semantic management of fmea
knowledge. International Journal of Computers, Communications & Control (2016)
19. Solé, M., et al.: Survey on Models and Techniques for Root-Cause Analysis. Clinical
Orthopaedics and Related Research (CoRR) (2017)
20. Souiden, I., et al.: A survey on outlier detection in the context of stream mining.
In: Advances in Intelligent Systems and Computing (2017)
21. Venceslau, A., et al.: Ontology for computer-aided fault tree synthesis. In: Emerging
Technology and Factory Automation (ETFA), 2014 IEEE. pp. 1–4. IEEE (2014)
22. YE: Big data: Changing the way businesses compete and operate (2014)
23. Ye, J., et al.: Semantic web technologies in pervasive computing. Pervasive and
Mobile Computing pp. 1–25 (2015)
24. Zhou, A., et al.: A research on intelligent fault diagnosis of wind turbines based on
ontology and fmeca. Advanced Engineering Informatics 29(1), 115–125 (2015)