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

Fig. 1. Monitoring, diagnosis, and fault handling overview: observer (yellow), diagnosis engine (blue), rule engine (green), [4] system consists of three parts. A set of observers which is used to detect a fault. A diagnosis engine which identifies the component which caused the fault. The usage of observers and a diagnosis engine for a ROS was already proposed in [3] and was extended in this paper. Finally, a rule engine is used to react to faults. To allow the method to be applied for already existing software, it is of interest that the used software components are not needed to be altered. Thus, instead of detecting a fault in the software components directly, we use information provided by the interaction of the software components. This allows that we can detect a fault without changing existing software components. This can be simply achieved in ROS by introspection on the topics which are used for the communication. By observing properties of a topic, e.g. frequency of communication on a topic, the system can be checked if it conforms to the given model. This observation is provided using different observers where each observer is used to determine if a specific property hold. We will discuss in the next section in more detail which observers exist. With the observations, only the robot would only be able to detect that a fault has occurred. But the robot needs also to determine which component caused the fault. This is of special interested if several malfunctions are detected at the same time. With the help of the model of the system and a reasoning process, the diagnosis engine determines which components are faulty. The reasoning performed uses a consistency-based diagnosis [5] approach which searches for a minimal set of components which are blamed for being faulty explain the observations. We discuss the diagnosis engine in more detail in Section IV. After the robot, has determined which components might have caused the fault the robot needs to react to this fault. This is achieved with the help of a rule engine which uses the current diagnosis of the system together with the obser- vations. By combining the diagnosis and the observations the rule engine can determine which rule should be triggered to execute a specific repair. This allows the robot to react in a timely manner. If a planning system would be used as it was described in [3] a possible high planning time may not allow such a fast reaction. Due to this reaction, the robot can bring itself intoasafe statewhichcanbeusedafterward toperform a more complex repair. Let’s consider a simple example. The robot detects that the laser scanner used for navigation is malfunctioning. After determining this malfunction, the robot can react and stop immediately. Thus, the robot will not drive into an obstacle. After the robot, has stopped, the robot can perform a more complex reasoning which repair should be performed with another method [3]. Or it may even try to reconfigure itself to deal with the fault [4]. In this paper, we will focus only on a quick reaction to a fault and not a complex repair or reconfiguration mechanism. We will discuss the rule engine in more detail in Section V. The complete system as it is described in this paper is public available under http://git.ist.tugraz.at/ ais/model_based_diagnosis. III. OBSERVERS As outlined above we use several observers to check if a certain property of the robotic system holds. These observers are used to mediate between the concrete messages send in the robotic system and the abstract model of the system. This allows that the model of the system uses a predicate based representation of the robotic system which simplifies the diagnosis process. Furthermore, the observers can use specifically design methods to observe a certain property allowing a small computation overhead to provide the observations. To properly supervise the system different types of ob- servers are used. Some observers observe the behavior of a node directly where others observe the behavior or the message exchanged. To observe the behavior of the node directly two observers can be used. • The activated observer checks if a node is present in the robotic system. Thus, allowing to check if the system is properly configured. • the resource observer checks if a specific node in the system uses a predefined amount of system resources, e.g. CPU. This allows checking if the node neither con- sumes too many resources, e.g. a memory leak causing the accumulation of memory nor the consumption of too fewer resources, e.g. no CPU usage as the node has deadlocked itself. To observe the behavior of the message exchange in the system the following six observers can be used. • The time-out observer checks if at least one message was sent within a specified time interval. This allows checking if a topic is used for communication and performs a watchdog functionality for a topic. Thus, allowing to revival problems which cause the commu- nication to break down, e.g. the node which should send an information can’t produce an output. • The HZ observer checks on a topic if messages are exchanged with a given frequency. This allows checking if a communication is done on a regular basis. Thus, allowing to check if the node which provides the information is overloaded. • The time-stamp observer checks if the timestamp of a message send is not too old. This allows checking if 10