Reliability.mediawiki

@@ -29,7 +29,7 @@ Reliability building block goal is to improve the reliability aspects of the uni
 
 ==Artefact #1 : Failure Diagnosis Module in universAAL==
 
-==== Blackbox Description ====
+=== Blackbox Description ===
 
 Fault Diagnosis is the process of determining the type, size and location of the most possible fault together with the temporal specification of the fault. Diagnosis is the reasoning process for detection, isolation, analysis and recovery of occurring faults. A Symptom is the subjective evidence of a failure that indicates the existence of fault. 
 
@@ -40,7 +40,7 @@ The main components for the diagnosis infrastructure for universAAL are as follo
 #Fault analyser : is the component which analyses the gathered error reports by detection unit based on diagnosis rules
 #Failure Notifier: is the component that typically gathers fault reports and publishes the diagnosis decisions
 
-==== Bundles ====
+=== Bundles ===
 {|  border="1" style="cellspacing=0; bordercolor=gray; align=left; valign=top;"
 ! align="left" bgcolor="#DDDDDD" colspan="2" | Artifact: '' Failure Diagnosis Module in universAAL ''
 |-
@@ -392,10 +392,7 @@ Propagate messages
 |}
 
 === Implementation of The Diagnosis Framework===
-==== Initial implementation from selected input projects ====
-There were no initial implementation from the input projects.
 
-==== Implementation Plan ====
 In this section, an integrated detection and diagnosis framework is presented that can identify anomalies and find the most probable root cause of not only severe problems but even smaller degradations as well. Detecting an anomaly is based on monitoring uAAL component profile (see the following section on Error Detection Unit). Diagnosis is based on reports of previous fault cases by identifying and learning their characteristic impact on different performance indicators.
 
 In common day terminologies, detection and diagnosis are hardly separated. Commonly, by the phrase “detecting a problem”, one often means two things actually: first, the confirmation that there is a problem at all and second, the verification of the nature or type of the problem itself. An example might be as follows. Sensors to register weight in the bed can activate the lighting of the route to the toilet, when the bed is left. But in one instance, it has been detected that the lighting does not activate although the bed is left because the weight sensor of the bed is generating no signal. The correct terminology in this example would be to say that an unusual behavior has been detected (i.e., the lights are not activated) and it is diagnosed that, e.g., the cause is a damaged sensor that has to be replaced. Detecting that the lights will not activate does not necessarily mean that there is a problem with the lighting itself; nevertheless, simply looking at the symptom level with this granularity it is impossible to tell if there is a serious problem with the lights or the master switch of the lights just has to be restarted. Therefore, if an unusual behavior is detected, a more thorough diagnosis has to be conducted in order to find out if there is actually a problem and what is the root cause behind it. Since the terms “detection” and “diagnosis” often carry an implicit duality, they have to be precisely defined before used in an engineering system such as an Ambient Assisted Living space: Detection basically means to identify something unusual in the network. However, in the context of the integrated framework in uAAL, the role of the detection process is only to provide a common view of possible indicators (symptoms) to the diagnosis to facilitate their correlation but deciding if there is a fault at all or what it is will be left to the diagnosis. Diagnosis means to investigate the root cause that could have caused the detected symptoms. In the framework, the input of the diagnosis is the output of the detection unit. The output of the diagnosis might as well be that there is in fact no problem at all. Usually, after the diagnosis of the root cause is done, certain corrective actions have to be performed in order to resolve the problem. Sometimes the root cause is harder to investigate than providing the action without knowing the underlying mechanisms; e.g., several failures can have a common corrective action (like restarting the sensor) but the root cause is unknown for the maintenance operator. It is even possible that the associated action is not a direct correction of the fault but the recommended escalation (e.g., alarming manual support line). Therefore, using the corrective action instead of the specific root cause is also acceptable. The root cause or the corrective action are what the diagnosis returns and they will be jointly referred to as the target of the diagnosis.
@@ -496,10 +493,7 @@ In order to realize the EDU, several assumptions and requirements should be take
 *Extendibility: The framework should be expendable to adapt to any new error detection mechanism.
 
 === Implementation ===
-==== Initial implementation from selected input projects ====
-There were no initial implementation from the input projects.
 
-==== Implementation Plan ====
 Before getting into the practical elements of the EDU and how these elements have been implemented, several design aspects might be clarified at first. One of the most important feature in EDU, is its ability to detect the errors in time domain, the error detection mechanism in time domain should be accurate enough to handle the timing errors in high resolution. Thus a high resolution time stamping and timer mechanisms need to be used. To cope with this issue, specific timing functions have been utilized from the OS (Linux OS in our case). Although this procedure might made the EDU a non-portable code, equivalent timing functions of other OS can be found and replace that of Linux.
 Because of that and to make the code more flexible, the main core of the EDU has been implemented in C Language and provided with native methods to make the interface to the middleware which is already implemented with java.
 To achieve the message classification inside the EDU, a pre-knowledge about the message specifications both in time and in value domain are required. These specifications should be delivered by the application developer at the design time and before the using of EDU. An XML configuration file has been created to make it easier for the developer to give the specification of its message. To manipulate the specification of the message, a parser function has been created for parsing the information from the XML file and providing them to the main data structure of the EDU.