In the rest of this chapter we elaborate on the idea of providing diagnosis functionality as a service accessible over the Internet. We provide an overview about necessary prerequisites, discuss the functionality to be delivered, and introduce model‐based diagnosis as a foundational method for implementing diagnosis as a service (∆aaS).
50.2 Prerequisites
Let us start first with all prerequisites we need for diagnosis. First of all, we require knowledge about the system we want to diagnose. This knowledge has to include rules to allow reasoning from causes to potential effects. The causes themselves have to be formulated in an explicit way, i. e., via introducing a hypothesis for each cause. For example, a switch might be on or off. These two states of the switch have to be represented as hypotheses, e. g., switch_on, switch_off, in a knowledge base. In addition, we need observations of the system, i. e., the symptoms. Based on the knowledge base for diagnosis and the observations we further need a reasoning engine that returns potential causes for the given observations. A potential cause in this terminology would be a hypothesis or a set of hypotheses that have to be true in order to explain the given symptoms. We will discuss the reasoning aspect in more detail in Sect. 50.3.
In summary, a diagnosis service needs the following information to compute diagnoses: A diagnosis knowledge base comprising knowledge about the system to be diagnosed, where the knowledge should allow reasoning from causes to effects and explicitly introduce hypotheses, and
A set of observations, i. e., the symptoms, to be explained.
Of course the necessary knowledge has to be available in a form that can be utilized by the underlying diagnosis reasoning‐engine. For the reasoning engine, we require efficient computation and also independence from the diagnosis problem itself due to the fact that systems in case of Industry 4.0 change their structure and thus their underlying behavior over time. Independence from the underlying diagnosis problem means to be general applicable regardless of the given diagnosis knowledge and observations.
A concrete ∆aaS implementation should take the information relevant for diagnosis, i. e., the knowledge base and the observation, as input, and deliver certain hypotheses explaining the observations as an output. This view, however, is rather limited because it only considers the diagnosis part of ∆aaS but not how to develop and maintain the knowledge base. Hence, a ∆aaS implementation should deal with both aspects. Note that the two tasks, i. e., (1) developing and maintaining the knowledge base and (2) using diagnosis, are usually performed by different persons having different skills. Task (1) requires knowledge about how to formulate the required knowledge, whereas (2) only needs information about observations (and the current state of the system). In addition, and especially in the context of Industry 4.0, task (2) may be automatically performed. Therefore, the interfaces to ∆aaS may be closely adapted for the different tasks.
In Fig. 50.1 we show the architecture of a concrete ∆aaS implementation and the underlying diagnosis method including the interactions with users, which can be by either humans or other systems. We distinguish the users of the diagnosis engine (System or Maintenance Personnel) and the ones responsible for providing the diagnosis knowledge (KB Creator), which is stored in a system model. The diagnosis engine takes the system model together with the observations and the system state, and returns explanations, i. e., the diagnoses.
Fig. 50.1∆aaS architecture
In the next section we discuss a diagnosis method that fits ideally the requirements of a ∆aaS as described before.
50.3 Diagnosis Methods and Techniques
A ∆aaS needs to be general enough to serve many purposes. Hence, we need an underlying diagnosis methodology that is as general as possible. In the early days of Artificial Intelligence (AI) rule‐based expert systems [4] have been used for diagnosis (see for example [1]). A rule can be seen as an if‐then construct, where the condition is a question to be answered by the user and a consequent the next possible state or a diagnosis results. Classical rule‐based systems implement the reasoning in the direction from symptoms to responsible causes. A main drawback of these kinds of system for diagnosis is that the rule‐base has to be always changed in case the system structure changes leading to high maintenance costs. Therefore, classical rule‐based systems can hardly be used in the given setting of ∆aaS. In order to avoid the mentioned problem, the concept of model‐based diagnosis has been suggested. We distinguish two types of model‐based diagnosis: (1) consistency‐based diagnosis (see [5] and [6]), and (2) abductive diagnosis [7]. In (1) only the correct behavior of a system based on the structure of the system and a formalization of the behavior of its parts has to be provided. In abductive diagnosis, rules that represent cause‐effect reasoning are used. Both types of model‐based diagnosis are very much appropriate in the context of ∆aaS because diagnosis only relies on the underlying models, i. e., a model of the system, and is thus generally applicable. It is also well known that both types have a strong relationship (see [8] for more information).
In this chapter, we suggest the use of abductive diagnosis and outline its underlying idea and concepts. The reason is that the necessary diagnosis knowledge can be easily obtained from system documentation available. For more information about the use of abductive diagnosis in industrial applications we refer the interested reader to [9].
In order to show the principles of abductive diagnosis and the required information, we make use of the following small example:
Example
Let us assume to come at home during the night. After unlocking the door and entering our home, we try to switch on the light at the entrance but there is no light. Maybe the bulb is broken. However, we first go to the nearby living room trying to switch on the light but again without success. We now have at least two potential causes. One states that the bulb at the entrance and the one in the living room are both broken. Another alternative explanation would be that the fuse responsible for the lights at the first floor is in state off or broken. The latter only requires one hypothesis to explain two symptoms. Hence, we would try to fix the problem using the smallest diagnosis first.
In this example, we use some implicit knowledge about the structure of the electrical system at home and about the behavior of involved parts, e. g., that a bulb has to submit light in case of being switch on, and that there are fuses for different electrical cables in order to prevent damage (mainly due to fire caused by too much electricity going through a cable). For automating diagnosis, we need a formal representation of the knowledge about the system.
Fig. 50.2 shows the structure of an electrical system we assume to correspond with our diagnosis example. In the schematics we see that we have one main fuse (F1) and two sub circuits with fuses F2 and F3 respectively. In the first sub circuit we have two switches connected (S1 and S2) turning on or off two bulbs (B1 and B2 respectively). In the second sub circuit we have two changeover switches S3 and S4 used to turn on and off bulb B3. From this schematic we are able to derive consequences, i. e., symptoms, of hypotheses. For example, when assuming that bulb B1 is broken, we know that B1 cannot emit any light. If fuse F2 is broken, we know that bulb B1 and B2 cannot be turned on anymore using switch S1 and S2 respectively. Similarly, we are able to derive what happens if both fuses F1 and F2 are not broken and S1 is set to on, then the bulb B1 should be on and thus transmit light.
Fig. 50.2Simplified schematics of an electrical system for a domestic home
Using this information we are able to construct a table where we have on one side the hypotheses and on the other their effects. Table 50.1 shows the entries only for the case of broken fuses or bulbs. For simplicity we do not consider the position of switches and the cases where a bulb is lighting. Table 50.1The cause‐effect table for the electrical circuit for a dom
estic home
Hypotheses
Effects
Broken(F1)
No_light(B1) AND No_light(B2) AND No_light(B3)
Broken(F2)
No_light(B1) AND No_light(B2)
Broken(F3)
No_light(B3)
Broken(B1)
No_light(B1)
Broken(B2)
No_light(B2)
Broken(B3)
No_light(B3)
The semantics behind the table is the following. In each row we have one cause‐effect pair. The cause is a hypothesis mentioned in a row, while the corresponding effects are given in the second column. If there is more than one effect, the effects are put together using local operators like AND or OR. In the second line we see that a broken fuse F1 influences all the bulbs. In case of an OR at least one of the effects must hold. It is worth noting that there might also be more than one hypothesis given in a row. For example, in case two or more hypotheses are necessary for deriving the mentioned effects.
In abductive diagnosis accordingly to the definitions from [7] a diagnosis is a set of hypotheses that allows deriving all given symptoms. In addition, we do not allow hypotheses in a diagnosis to be contradictory, e. g., a diagnosis that would state that a fuse is broken and not broken at the same time is not a diagnosis. A diagnosis is said to be parsimonious if none of its subsets are themselves diagnoses. In practice, we are mainly interested in parsimonious, i. e., minimal, diagnoses.
Let us come back to our initial example. When entering our home we see that there is no light at the entrance, i. e., the observed symptom is No_light(B1). From Table 50.1 we know that Broken(F1), Broken(F2) or Broken(B1) are all valid diagnoses because they have No_light(B1) as effect and thus allow to derive the given symptom. When turning on the next light, i. e., B2, we obtain two symptoms No_light(B1) AND No_light(B2). Hence, we have two single hypothesis explanations, i. e. Broken(F1) as well as Broken(F2). Another larger explanations is Broken(B1) AND Broken(B2). When preferring smaller explanation, we would first have a look at the fuses.
The abductive diagnosis approach as described can be extended to handle probabilities for diagnosis and also to support the user during the process of localizing the root cause. For example, the probability that a bulb is broken is often much higher than the probability of a broken fuse. This information can be utilized to rank diagnoses according to their likelihood. The diagnosis process itself includes adding new observations or measurements, i. e., symptoms, to further reduce the number of diagnoses, or to make appropriate repair actions.
50.4 Diagnosis
Continuous growth in magnitude and complexity of technical systems requires automatic diagnosis procedures to determine failure inducing system parts effectively. Particularly, in domains where maintenance costs constitute a significant portion of the life‐cycle costs accurately deducing the root cause of an anomaly is essential. The industrial wind turbine domain is an application area experiencing a cost‐intensive maintenance process. In this section we focus on improving fault diagnosis in real applications such as wind turbines by employing abductive model‐based diagnosis to compute causes for measurable system anomalies.
The main hindering factor influencing the dissemination of model‐based diagnosis in practice is the initial effort associated with the creation of a suitable system model. We devised a process that aims at integrating abductive diagnosis in real‐world applications by automating the development of system models. By reusing knowledge frequently available, such as Failure Mode Effect Analysis (FMEA), the model creation time as well as cost necessary is decreased. Fig. 50.3 depicts the process that is divided into three main stages, i. e., (1) model development, (2) fault detection and (3) fault identification [9].
Fig. 50.3Process for incorporating abductive model‐based diagnosis into an industrial setting [9]
As the knowledge necessary for abductive reasoning describes the connection between causes, i. e. hypotheses, and their effects, i. e. symptoms, failure assessments such as FMEA provide appropriate information for abductive diagnosis, as they capture knowledge on causal relations between components based fault modes and their effects on system variables.
Table 50.2 shows a simplified FMEA taken from the industrial wind turbine domain. As can be seen there are three columns describing the relation between components, their fault modes as well as their effects on the system. Consider the first entry. This states that in case the pins of the fan are experiencing corrosion, an unexpected decrease in the generated power (Power(Turbine,low)) and an increase in the cabinet temperature (Temperature(Cabinet,high)) are observable. Table 50.2Exemplary FMEA of the converter of an industrial wind turbine
Component
Fault Mode
Effects
Fan – Pin
Corrosion
Power(Turbine,low), Temperature(Cabinet,high)
IGBT – Wire Bonding
High‐cycle fatigue (HCF)
Power(Turbine,low),
Temperature(Inverter_Cabinet,high),
Temperature(Nacelle,high)
There are two essential characteristics of the FMEA which we have to consider when mapping it to a cause‐effect table. First, each fault mode is associated with a specific component. Thus, the hypotheses we are considering for our cause‐effect table are a combination of a component and its fault mode. For example, the hypothesis inferred from the first entry would be Corrosion(Fan–Pin) implying that the pins of the fan are corroded. Further, all effects have to be connected by an AND as in case the fault is present all symptoms have to be existent. Table 50.3 depicts the cause‐effect table created on basis of the FMEA in Table 50.2. Table 50.3The cause‐effect table for the converter example
Hypotheses
Effects
Corrosion(Fan–Pin)
Power(Turbine,low) AND Temperature(Cabinet,high)
HCF(IGBT – Wire Bonding)
Power(Turbine,low) AND Temperature(Inverter_Cabinet,high) AND Temperature(Nacelle,high)
Once the system model has been created offline, the online portion of the process takes place. Diagnosis is always triggered by the observation of a symptom. Therefore, some mechanism must be present to determine a deviation from the expected to the current system behavior, i. e. a fault detection method. In the wind turbine domain a condition monitoring system provides information on anomalies among the system variables.
After a symptom has been observed, the diagnosis reasoning engine can be started. The engine takes as input on the one hand the system model generated offline and on the other hand the results of the fault detection, which are fed into the engine as observations about the current system state. The diagnosis engine then determines the hypotheses explaining the observations. Information such as probabilities can be used to refine the diagnosis and additional measurements aid in reducing the number of solutions and confirming diagnoses.
We conducted several experiments on the diagnosis computation time for various FMEAs publicly available and project internal. The FMEAs analyze electrical circuits, a connector system by Ford, the Focal Plane Unit (FPU) of the Heterodyne Instrument for the Far Infrared (HIFI), printed circuit boards (PCB), the Anticoincidence Detector (ACD) of the Fermi Gamma‐ray Space Telescope, the Maritim ITStandard (MiTS), as well as rectifier, inverter, transformer, main bearing, and backup components of an industrial wind turbine. Table 50.4 depicts information about the size of the model, i. e., #Hyp and #Eff determine the number of hypotheses and effects. The runtime results show the minimal, maximal, average and median runtime in milliseconds. The last five columns display the maximum and average number of diagnoses as well as the number of single hypothesis (S), double hypotheses (D) and triple hypotheses (T) diagnoses. Table 50.4Experiment results on various FMEAs [9]
Model Size
Runtime [in ms]
#Diagnoses
System
#Hyp
#Eff
MIN
MAX
AVG
MED
MAX
AVG
S
D
T
Electrical Circuit
32
17
< 1
994
48.0
2
792
191.6
11
22
44
Ford
Connector
System
17
17
< 1
204
2.1
1
18
3.1
6
18
18
HIFI‐FPU
17
11
< 1
214
5.2
1
189
8.2
7
21
27
MiTS1
17
21
< 1
307
7.6
1
12
5.4
3
3
6
MiTS2
22
15
< 1
191
6.6
2
288
37.4
Digital Marketplaces Unleashed Page 77
