Seite - 11 - in Proceedings of the OAGM&ARW Joint Workshop - Vision, Automation and Robotics

old data are sent in the system thus reveal problems to produce new data. • The timing observer checks the time difference between one message send on one topic and one message sends on another topic. This can be used to check if a node produces an expected output within the expected time frame. Thus, one can detect if a processing step takes too long. • The score observer checks if the float value of a topic is within a range. This allows checking the calculated score, specifying the performance of an algorithm out- come. • The movement observer uses two topics which specify the movement of the robot for correlation. This correla- tion can be used to check if the expected movement differs significantly, e.g. the movement measured by the IMU is different to the movement measured by the odometry. Using the different observer types different properties of the system can be checked. As the observations, may be subject to noise one cannot simply use the raw values to perform the check. Instead one can apply different filter mechanism to process the raw values before performing a check. Thus, the raw value to check, e.g. the frequency of a topic is treated as a signal which needs to be filtered as it is common in signal processing [6]. After filtering the raw values of the observation one needs to perform a check to determine if the observed values are acceptable. This can be done by simple checks which determine the correctness using comparison with a fixed value. But it is also possible to use a more complex test which uses a statistical approach. This is done by performing a student-t-test [7] on the filtered data. Through this test one can check if the hypothesis that the observation is acceptable needs to be withdrawn. Thus, allowing to perform a check considering the statistical uncertainty. All except one observer type check the raw value observed with a nominal value of the mode, e.g. the frequency of a topic with the expected value. The movement observer is the exception, as it correlates two values with each other. The idea is to use the redundant information in the robotic system to check for consistency. This follows the idea of residuals [8] which create an error term between redundant information in thesystem.Todoso,wefirstderive fromeachmovementmeasurement the resultingacceleration. Thus, if the movement is given by the current velocity the movement isdifferentiated toget theacceleration.Afterward, the accelerations of one input are subtracted from the other input. If no fault occurs this value is zero. Due to the noise measurement, the value follows a Gauss distribution with zero mean. With the help of the filter methods, one can estimate the mean of the distribution and use this estimation to perform a check if the value is close enough to zero. IV. DIAGNOSIS ENGINE Using the observers one can detect if one property of the system behaves not as defined. This allows to detect a fault but does not allow to isolate the faulty component directly. Instead one needs to perform a reasoning. We use the idea of consistency-based diagnosis [5] to perform this reasoning. The reasoning uses the information about the observations taken from the system as well as the topology of the system. This allows handling fault propagation properly. To specify the system, we define a system to consists of a set N defining the nodes of the system. These are the software components which are running and need to be diagnosed. Additionally, the system consists of a setM defining the topics which are used to exchange messages between the software components. To represent the input topics to a node we use the function input :N→2M. The output which is produced by a node is defined through output :N→ 2M. Using the setN, and the functions input andoutput one can describe the informationflowof thesystem.This information flow is of interest as a fault can be propagated along this information flow. To define a software component n to be faulty we use the predicateAB(n). Besides the software component also a topic can be observed to be faulty thus we writeAB(m) that on observation indicate that the message exchangem is not as expected. Please note that we are only interested in the predicatesAB(n) which are used to explain a faulty behavior. Thus, we will search for a minimal set ofAB(n) predicates which explain the observations. To specify the fault propagation, we use the following logical formula which is defined for eachn∈N. ∀mo∈output(n) :AB(mo)→  AB(n) ∨ mi∈input(n) AB(mi)   The formula states that if the output of a software component seems to be faulty either the component is faulty or one of its inputs where faulty. Thus, one can propagate the fault from input to output. With the help of the above formula, we can define the fault propagation in the system per the structure of the system. Besides the structure of the system, we need also to define how the observations made a link to the components in the system. This link depends on the type of observation made. We use the following formulas to link the observations and the components of the system. • If componentn is observed with the help of an activated observer (obsactivated(n)) we state the following logical formula. ¬obsactivated(n)→AB(n) As we directly observe the component we can detect that the component is faulty if the observation indicates a fault. • If componentn is observed with the help of a resource observer (obsresource(n)) we state the following logical formula. ¬obsresource(n)→AB(n) 11