Intelligent Agents Diagnostics—Enhancing Cyber‐Physical Systems with Self‐Diagnostic Capabilities

Allowing intelligent agents to deal with unforeseen situations that have not been considered during development in a smart way is a first step for increasing their autonomy. This requires diagnostic capabilities to detect the unforeseen situation and to identify a root cause that can be used afterward for carrying out repair and other compensating actions. Herein, foundations for diagnostic reasoning based on models of the system are provided. In particular, a diagnostic solution is presented that utilizes answer set solvers, which allow implementing non‐monotonic reasoning. The underlying ideas are introduced, an algorithm is discussed, and experimental results are obtained to clarify the question whether the approach can be used in practical applications. The obtained results indicate that answer set solving provides similar and sometimes even better results than specialized diagnosis algorithms, and can be used in practice.


Introduction
Intelligent systems with increased autonomy have not only to be aware about their environment and consequences of actions, but require to deal with internal faults as well, to prevent others from harm. For example, an autonomous car may not stop operation on a highway directly after a bend where other arriving cars may not be able to stop in time when approaching due to limited sight. For automated cars where there is a human driver as a fall-back available, such situations are less problematic. A detected failure would lead to passing control to the driver directly who is responsible for any actions. In case of autonomous systems, however, such a human fall-back mechanism is hardly available. Therefore, smart diagnosis seems to be mandatory for autonomous systems and other types of intelligent agents.
In this article, we discuss the use of model-based reasoning [1][2][3][4] for providing diagnostic capabilities for embodied intelligent agents in the context of cyber-physical systems (CPSs). Model-based reasoning utilizes a model of a system directly to obtain solutions for diagnosis and other problems. The underlying idea is to introduce models of the ordinary behavior of components of the systems, and in some cases also fault models, and to make assumptions about which model to apply considering current observations explicitly available. Diagnosis becomes search for modes, such that the corresponding behavior does not contradict the given observations. The application of model-based reasoning to CPS is unfortunately not that straight forward. First, CPSs are systems interacting with the physical world requiring physical models, e.g., differential equations, in combination with models of the computational state of the particular CPS. In the original setup model-based reasoning relied on logical descriptions of models, which can hardly be used directly to cope with physical models. Second, we have to deal with not only the intended behavior of a system but also with models corresponding to faults wherever such models are available to allow the CPS to react on faults more specifically. Again dealing with fault models has been not in the scope originally but was introduced later (see the previous study [5] ). Third, model-based reasoning is computationally demanding, and we need efficient reasoning engines. This holds especially in the context of CPSs, because there we want to introduce diagnosis functionality that is capable of monitoring and diagnosing the system at real time. Finally, there is a need for coming up with a solution that can be easily integrated into a CPS and also does not change the overall development process (at least to a larger extent).
We contribute to these challenges arising when applying model-based reasoning in the context of CPS. In particular, we discuss how models of CPSs can be obtained using value abstraction, and we show how state-of-the-art logical reasoning systems such as answer set programming (ASP) [6] can be used for diagnosis including the use of fault models, and we further discuss how diagnostic capabilities can be integrated into every CPS. For the latter, we introduce a system architecture that allows to couple control systems with diagnostic reasoning capabilities. In addition, we extend previous work, for example, see the previous study, [7] on using ASP for diagnosis integrating fault modes for diagnosis and present results obtained from a more detailed experimental evaluation.
We organized this article as follows: In the next section, we motivate research in diagnostics for CPSs using an example from the autonomous robotics domain, i.e., a direct current (DC) motor driving a wheel. There we briefly discuss the corresponding challenges regarding how to detect faults, and how to derive diagnosis in an informal way. In Section 3, we outline how an embodied intelligent agent can be equipped with diagnostic reasoning capabilities. For this purpose, we introduce an architecture and discuss its components for monitoring and diagnosis. Afterward, we introduce the basic foundations behind modelbased reasoning in Section 4, and its implementation and algorithms using ASP in Section 5. Finally, we present our experimental evaluation and discuss the obtained results in Section 6, and summarize the article in Section 7.

Motivation
Intelligent systems such as software agents or mobile robots interact with their environment and may suffer from undesired environmental changes, faulty perception, or internal faults. In the following, we discuss an example from the mobile robotics domain comprising a DC motor, together with control, a wheel, a wheel encoder, and a power supply. Such systems are used in a robotics drive to move the robot from one position to another or turn the robot. For a differential drive, we have two such systems allowing to move the robot to any position. In Figure 1, we outline the components of such a system. Let us consider now that the robot should move from the current location to another location, and that at a particular point in time, one wheel gets stuck.
In such a situation, the robot (or at least one wheel) cannot move forward anymore. The robot may turn if the other wheel is still active, causing not reaching the desired location anymore. An intelligent system has to detect such a situation and to react in a smart way. The former requires to compare the expected behavior of a system with the currently observed behavior. The latter has to lead to diagnosis, i.e., the identification of the root cause of the observed problem and, finally, to repair that may come with compensating actions to be carried out. For our mobile robotics example, we need to identify that there is a deviation between the expected and observed behavior, and to conclude that one wheel is blocked. For these activities, the robot can only make use of available information.
Let us have a closer look at available information and corresponding knowledge. From the system, we definitely know the expected mode of operation, i.e., that the motor should be one driving the connected wheel. We also know that a rotating wheel has to induce a rotational speed that can be measured using the wheel encoder. We may also have additional sensor such as the current flowing through the DC motor required to run it. In Figure 2a, we see the expected behavior of such a  www.advancedsciencenews.com www.advintellsyst.com robot, where at time 0, the motor is expected to be stopped. At time 0.5, the motor should start working at half speed, and at time 1 at full speed. After time 2, the motor should stop again. This expected behavior is caused by the control command (green, full line). As an effect of this command, we see that the rotational speed (blue, dashed line) and the required current (red, dotted line) follow a particular behavior. The speed is increasing until reaching a maximum and dropping to zero after stopping the motor. The current consumption has a peak when starting the motor and further accelerating it. When stopping, there is an induced current flowing in the opposite direction. All this behavior can be modeled using a physical model of the motor and its corresponding parts.
In case of a stuck wheel, the behavior of the system changes. In Figure 2b, we show this faulty behavior. Until time 1.5, both behavior trajectories are the same. At time 1.5, the wheel gets stuck causing the rotational speed to decrease until reaching 0. Because of the fact that the motor still tries to rotate, the used current increases a lot exceeding the expected value. When stopping the motor (and in this case also releasing the stuck fault), the motor is again running until now further electrical energy (and, therefore, induced current) is in the system. When being able to make use of these described differences for diagnosis, the robot would be able by itself to recognize such a situation and-if programmed accordingly-to react in a smart way, i.e., stop driving forward and try to move backward to get out from being stuck. Therefore, we argue that for truly intelligent agents, it is inevitable to implement diagnostic reasoning capabilities.
From the motivating example, we are further able to deduce that diagnosis may not depend on a physical model considering concrete values. Instead, we often use more qualitative arguments for justifying our beliefs. In the mobile robot drive example, we argued that certain values increased or decreased to some causes resulting in the wrong behavior, i.e., that the wheel is not rotating anymore. Hence, a qualitative representation of the behavior seems to be sufficient in many cases. It is worth noting that this has been observed in artificial intelligence research decades ago, leading to the research area of qualitative reasoning (QR). [8,9] For our example, we may define the expected behavior using qualities such as a speed value to be zero, medium, or high instead of considering the detailed quantitative behavior. In Table 1, we summarize such a qualitative behavior of the DC motor, the wheel, and the wheel encoder, which are connected with each other. For the DC motor, for example, we consider the input voltage, the expected current required to drive the motor, where we only distinguish a nominal and a high value, and the expected speed.
In summary, we conclude that diagnosis is an important property of intelligent agents to deal with unexpected situations that arise due to unforeseen interactions with or changes in the environment, wrong perceptions, and also internal faults. Qualitative representations of the behavior of an intelligent agents may be sufficient for diagnosis, i.e., for arguing about the correctness of a cause leading to the observed effect. In the next section, we further discuss an overall system architecture for intelligent agents that is capable of providing observations, mapping them to their qualitative representation, and coming up with diagnoses that can be afterward used for actions leading back to a desired state of the intelligent agent.

Monitoring for Diagnosis
After discussing requirements and needs for adding diagnostic capabilities to intelligent agents, we introduce a general diagnosis architecture that can be easily added to any CPS-based agent interacting with the real world as its environment. In Figure 3, we show such a framework comprising the original intelligent agent, e.g., a mobile robot used for transportation, on the lefthand side. This agent follows the sense-plan-act control paradigm, where the agent receives inputs from the environment using its sensors, e.g., a camera, plans for new actions to be executed to follow a particular goal, and executing these actions making use of the actuators, e.g., motors. It is worth noting that the proposed diagnostic framework is not limited to such kind of intelligent agents, but only requires to obtain information regarding sensor values, the internal state, and also actuator values.
The values obtained from the system to be diagnosed are managed using a monitoring component. In case of CPSs, the monitoring will happen at particular points in time and usually regularly considering capturing important value transitions of the system. This sampling rate for obtaining observations depends on the system itself and how fast it is expecting to interact with the environment. The Nyquist-Shannon sampling theorem provides a basis for obtaining the sampling rate. It is also worth noting that the monitoring component needs not to consider all values of signals exchanged within the context of the system to be diagnosed. Only signal values of interest for diagnostic purposes need to be captured. Furthermore, the monitoring component maps the obtained qualitative values of the intelligent agent into a qualitative representation used for diagnosis. For example, a value of 2.1 might be mapped to "high" whereas 1.5 to "low." These qualitative values are used by the diagnostics component for computing diagnoses to be feed back to the intelligent agent to be used for adapting its behavior.
The monitoring component also needs to consider time when coming up with qualitative values and calling the diagnostics. For example, let us consider the behavior of our motivating example from Section 2 shown in Figure 2. Although the fault happens at time 1.5, the wheel speed reaches zero after a certain amount of time. Also, the current consumption reaches its top after a time and not immediately after a fault. Hence, we need to consider two aspects. First, the monitoring component needs to detect a deviation from the ordinary behavior. This can be implemented using a simulation model of the system running in parallel. Second, after a deviation is observed, it might be requested to further wait until the system reaches a stable behavioral condition. The waiting time depends on the time behavior of involved physical processes and has to be engineered appropriately. Once a deviation is observed and the waiting time is reached, the monitoring system can obtain the qualitative representation of the signal values and call the diagnostics. In case of our motivating example, we would start diagnosis at time 1.9, mapping the current to "high" and the speed of the wheel (or the frequency of the corresponding wheel encoder) to "zero." In addition, we would map the control command to the voltage level of "high," indicating that the agent wants the motor to run at highest speed. The diagnostics is triggered by the monitoring component taking its qualitative values as inputs and utilizes the available model for computing diagnoses. The model itself shall capture the important relationships between signals to allow deriving potential root causes. In case of the motivating example, this might be a stuck wheel. These diagnosis are feed back to the intelligent agents to be capable changing its behavior in a smart way. A diagnosis may cause the agent to replan to reach a goal or to consider faulty actuators or even sensor values when planning the next steps.
In the next section, we discuss how diagnosis is carried out, show how modern theorem provers can be used for computing diagnoses, and present runtime results obtained using digital combinational circuits as benchmarks for showing that the approach is feasible in practice.

Diagnosis Foundations
Model-based reasoning and, in particular, its application for diagnosis has been an active research since the 1980s of the last century. Diagnostic reasoning based on models of a system comes in two flavors, i.e., consistency-based diagnosis [2][3][4] and abductive diagnosis. [10,11] Both diagnosis methods deal with explaining an observed behavior using cause-effect knowledge. In case of classical consistency-based diagnosis, which is often referred as model-based diagnosis, only the correct behavior of system components is used for obtaining diagnosis, whereas abductive diagnosis utilizes knowledge about a fault and its corresponding effects. It is worth noting that we can also introduce correct behavior into abductive diagnosis [12] and faulty behavior into consistency-based diagnosis. [5] Note that for intelligent agents especially in the context of CPS, it seems to be useful to also consider knowledge about faulty behavior when searching for explanations in case of observed failures. In the robotic's drive example discussed in Section 2, we argued that a wheel that is stuck consumes more current from which we are able to conclude that this is a reasonable explanation for the given observations.
To be self-contained, we briefly introduce the foundations behind consistency-based diagnosis but consider, in addition, the faulty behavior of components. For a more detailed discussion on the different diagnostic methods and their use in the context of CPS, we refer the reader to more recent publications. [13,14] A system comprises a finite set of components Comp ¼ fc 1 , : : : , c n g each having modes Modes ¼ f¬ab, ab, m 1 , : : : , m k g assigned. Note that ab stands for abnormal indicating the unknown faulty behavior and, therefore, ¬ab the known correct behavior. We further introduce a function Γ∶Comp ↦ 2 Modes mapping components to their assigned modes, where ab and ¬ab have always to be part of the component modes.
For each component c and mode m ∈ ΓðcÞ, except ab and ¬ab, there is a behavior behavðc, mÞ assigned. Without restricting generality, we assume that behavðc, mÞ is a set of the first-order logic clauses. The model of a system SD(SD stands for system description) comprises the models of the system's components and a model Struct representing the structure of the system and integrity constraints, i.e., SD ¼ ∪ c∈Comp,m∈ΓðcÞ ðmðcÞ ⇒ behavðc, mÞÞ∪ Struct∪Constr. Note that in Struct, we formalize connections between the components. In Constr, we formalize that, for www.advancedsciencenews.com www.advintellsyst.com example, a certain connection between components can only take one value at any time.
Let us construct a model for the example system given in Figure 1 considering the behavior stated in Table 1. This system comprises three components Comp ¼ fm, w, eg. For the motor m and the wheel w, we further introduce models for faults "broken" and "stuck," respectively, i.e., Modes ¼ f¬ab, ab, br, stg, where ΓðmÞ ¼ f¬ab, ab, brg, ΓðwÞ ¼ f¬ab, ab, stg, and ΓðeÞ ¼ f¬ab, abg. In case a motor is broken regardless of the input voltage, there will be no current consumption and no rotational speed provided. A stuck wheel causes the input and output rotational speed to be zero. The system model SD M comprises the following rules where v stands for voltage, c for current, s for speed, and f for frequency In SD M , the last line formalizes the connections between the motor and the wheel, and between the wheel and its encoder. To complete the model, we further need to state that a certain value of a quantity; e.g., vðmÞ cannot have more than one value at any time. For this purpose, we introduce integrity constraints as follows.
All these additional constraints are added to the model SD M . Besides this model, we need the observations for diagnosis. The observations Obs are again assumed to be the first-order logic clauses specifying certain values for observable quantities of the system. These values originate from the monitoring component of the diagnostic architecture discussed in Section 3. For our example, Obs M is fvðmÞ ¼ high, f ðeÞ ¼ zero, cðmÞ ¼ highg.
Given all information regarding a system and its current behavior, i.e., SD and Obs, we are able to define a diagnosis. For this purpose, we first define mode assignment that is a subset of the set fmðcÞjc ∈ Comp, m ∈ ΓðcÞg, such that for any component, there is exactly one mode assigned. A diagnosis Δ is a mode assignment, such that SD∪Obs∪Δ is satisfiable (i.e., consistent).
Considering SD M and Obs M from our example, it is easy to see that fbrðmÞ, ¬abðwÞ, ¬abðeÞg cannot be a diagnosis, because from brðmÞ and SD M , we can derive cðmÞ ¼ zero contradicting cðmÞ ¼ high from Obs M . The mode assignment f¬abðmÞ, stðwÞ, ¬abðeÞg, however, is a diagnosis.
In case of multiple diagnoses, we are interested in a preference criterion, allowing us to select the best diagnosis. In practice, someone is interested in preferring the smallest diagnosis, which is a diagnosis where only the least number of components is considered to be faulty. We may also want to find diagnoses, where we know that there is no subset that is itself a diagnosis. When dealing with fault models, we have to adapt the original definitions of minimality (see, e.g., the previous study [4] ). We first introduce a function NAB mapping a mode assignment to a set of components where all components are assumed to behave correctly in the given mode assignment, i.e., NABðΔÞ ¼ fcj¬abðcÞ ∈ Δg. Using this function, we come up with two definition of minimality of diagnosis. 1) A diagnosis Δ is minimal if there is no mode assignment Δ 0 that is itself a diagnosis, and where NABðΔÞ ⊂ NABðΔ 0 Þ. 2) A diagnosis Δ is parsimonious if there exists no other smaller diagnosis Δ 0 , i.e., ∄Δ 0 ∶jNABðΔÞj > jNABðΔ 0 Þj.
The first definition deals with minimality using a subset (or superset) relationship. The second definition considers minimality in terms of the least number of components to be faulty.
In the following section, we discuss how model-based diagnosis can be encoded in a way, such that ASP reasoning engines can be used for computing diagnoses. In addition, we present an algorithm that computes diagnoses up to a predefined size calling an ASP solver.

Diagnosis Using ASPs
ASP is a declarative programming paradigm based on logic programs and their answer sets. Many ASP tools are nowadays available (such as clingo [15] ) having the main objective enabling users to rapidly solve computationally difficult problems. The manner in which an ASP can represent a diagnosis problem was already introduced in the previous study [7] but focusing on models of the correct behavior only. In the following, we extend this work, showing how fault models can be integrated and, furthermore, discuss a diagnosis algorithm that allows computing subset minimal diagnoses up to a pre-defined size. This algorithm is an extension to the ConDiag algorithm introduced in the previous www.advancedsciencenews.com www.advintellsyst.com study. [16] Unlike ConDiag, we make use of an ASP Solver for computing the diagnoses and additionally consider strong-fault models.
In the following, we briefly explain how ASP can be used for diagnosis. ASP makes use of the concept of answer sets that are models of logical theories where every proposition in the model has an acyclic logical derivation from the given logical theories. A model in terms of logic is an interpretation, i.e., a function mapping truth values to propositions, that makes the theory true, i.e., is not contradicting the theory. An answer set for the theory a ∧ ða ! bÞ is fa, bg, because assuming a and b to be true satisfies the given logical sentence. Note that there is no answer set for the sentence ða ! bÞ ∧ ðb ! aÞ, because this theory is not acyclic. An interesting theory is the following: ð¬a ! bÞ ∧ ð¬b ! aÞ. In this case, we have two answer sets fag, fbg because of either a or b is true (but not both), we have a satisfiable situation considering the given theory. For model-based diagnosis, we make use of this consequence of the definition of answer sets. In the following, we use the syntax of the ASP implementation clingo, which is an extension of Prolog's syntax, for outlining how diagnosis models can be constructed.
We first represent a way allowing an ASP solver such as clingo to choose among truth values. From the definition of diagnosis, we know that we have to specify the health state of components and to check whether this assumption leads to a contradiction considering the model SD and the given observations Obs. Let us assume that we have a component c ∈ Comp having the health modes ΓðcÞ ¼ f¬ab, abg only. We map these health states to predicates nabðcÞ and abðcÞ, respectively. We can represent this information now as follows.
nab(c) :-not ab(c). ab(c) :-not nab(c) Note that :-represents the logical implication ←. In addition, we also have to specify the behavior of a component. Let us do this for the wheel encoder used in our motivating example.
val The encoder has one input for speed s and one output for the delivered frequency f. The upper model of the encoder is generally applicable for any encoder where using a variable E. If we have a particular encoder such as e, we only need to add the fact encoder(e) to the model. The first three rules map the input value to the output, and the others the output value to the input. We make use of the nab predicate to indicate that this behavior is only given in case the encoder is working, i.e., is not abnormal.
In addition to the behavior, we have also to specify integrity constraints stating impossibilities such as that the speed can take several values at the same time. This can be formalized using clingo syntax as follows.
:-val(E,X,zero), val(E,X,medium) :-val(E,X,zero), val(E,X,high) :-val(E,X,medium), val(E,X,high) These three rules do not only hold for encoders but for any component E where a port, i.e., an input or output, takes the particular value. Formally, these rules state that having a different value for a component and its port leads to an inconsistency. Furthermore, clingo also allows adding constraints regarding the size of a diagnosis. For this purpose, we are able to specify a set of predicates that are true in a particular answer set and to constrain the size of this set. For example, we can specify the abnormals occurring in an answer set and to count their number. numABs(N) :-N ¼ #count { X : ab(X) } The predicate numABs(N) is true for a particular value N in any answer set. If we are interested in single faults only, we add the rule :-not numABs(1) to SD, indicating that we are not interested in answer sets where there is not a single fault. This coding allows us to map diagnosis to ASP. However, the question remains: how to handle fault models in this context?
For the solution, we make use of the same ideas such as those used for representing the correct behavior and the unknown abnormal one. If we have modes Modes ¼ f¬ab, ab, m1, : : : , m k g, we represent ¬ab and ab as already described. For each m i , i ¼ 1, : : : , k, we introduce the following rules.
m i (C) :-not nm i (C) nm i (C) :-not m i (C) Hence, for each fault mode, we introduce two predicates, one representing the fault mode and one its negation. This allows again any ASP solver to set truth values accordingly when computing answer sets. Furthermore, we may want to specify that all fault modes are specializations of the unknown fault ab. This can be done as follows.
ab(C) :-m i (C) This allows us to search again for diagnoses of a given number of incorrectly working components. In addition, we also need to specify that any component is only allowed to take one fault mode at the same time. Again, we can use integrity constraints for every combination of i and j 6 ¼ i from 1, : : : , k.
:-m i (C), m j (C) In addition, we have to specify a concrete behavior for each fault mode. For example, the fault model for the wheel being stuck from our running example would be represented as follows.
st ( In this representation, we do not have integrity constraints on fault modes, because there is only one specified for wheels. As one further extension, we may make use of the number of strong fault modes used in a diagnosis to further guide diagnosis search. Similar to the abnormal case, we would count the number of elements in the set of all fault modes active in a particular answer set. numFM(N) :-N ¼ #count { X 1 : m 1 (X 1 ); : : : ; X k : m k (X 1 ) } After discussing how models can be representing using ASPs and, in particular, clingo, we now present a diagnostic algorithm. Algorithm 1 gives the algorithmic description of ASPDiag. ASPDiag takes as input the ASP representation of the system description and the observations, and the desired cardinality up to which all minimal diagnoses are to be computed. The www.advancedsciencenews.com www.advintellsyst.com ASP representation is the one described in this section, ignoring the integrity constraints for the number of abnormal. The algorithm starts with setting the found diagnoses DS to the empty set and the current model considered M f to the model of the system M. Afterward, it computes diagnosis of a certain size iteratively starting with 0 and ending with n (Line 3). In each iteration in Step 4, the limit of the number of abnormal predicates is added to the ASP model. In Step 5, the ASP solver is called returning a set of answer sets. The function F filters the answer sets only returning diagnoses as defined in this article. Steps 6-8 capture the case where there is only the empty set returned as diagnosis, which means that the system works as expected. In this case, the algorithm terminates. Otherwise, we add the new diagnoses to the diagnosis set DS in Step 9 and extend the model M f used to compute diagnosis. In Steps 10-13, we add integrity constraints stating that we are not interested in supersets of already found diagnosis. This is done as follows: For a diagnosis Δ, we first compute a set of components having an abnormal fault mode assigned. This is done using the function ABðΔÞ ¼ fcjabðcÞ ∈ Δg. For all elements of this set, we state that they should not occur at the same time anymore. We achieve this behavior via adding a corresponding integrity constraint in Line 12.
It is easy to see that ASPDiag terminates and computes all minimal diagnoses up to the predefined size. Termination of course requires the underlying ASP solver to terminate as well. Because ASP solvers work on grounded logic this has to be the case. Minimality of results is assured because of the used integrity constraints in Line 12. Computational complexity is of course at least non-polynomial complete, because ASP solving based on satisfiability solving requires exponential time in the worst case. The question is now whether the proposed approach can be used, in practice, for efficient diagnosis. We clarify this question in the next section where we present obtained empirical results.

Evaluation
To show that the presented diagnostic approach based on ASP is feasible for practical applications, we carried out an initial experimental evaluation based on Boolean combinational circuits. For the evaluation, we implemented the described diagnosis algorithm in Java and in Python. Both implementations rely on the ASP solver clingo (see the previous study [15] for more information). We further compared the outcome with a Java implementation of a specialized diagnosis algorithm that was also used in a previous paper [17] comparing different diagnosis algorithms. Note that the presented evaluation also substantially extends previous work of one author, [7] which only relies on single fault diagnosis not considering fault models.
The questions behind our experimental study are: 1) Showing the feasibility of using ASP solvers for diagnosis considering up to triple faults; 2) clarifying whether there is a substantial influence on the implementation language; and 3) providing first experimental results when introducing strong fault models into diagnosis based on ASP solving. We carried out the study making use of the well-known ISCAS85 benchmark circuits, which have been used often for comparing diagnosis algorithms, e.g., in the previous study. [17] In Table 2, we summarize statistical data of the different circuits ranging from 160 to more than 3512 components. For the study, we compiled the circuits into their ASP representation as described in the previous section. We came up with two representations. One capturing only the correct behavior, and the other in addition including strong fault models and in particular stuck at 0 and stuck at 1 faults. Furthermore, for each circuit, we made use of the same observations that have been used previously in the previous study. [17] It is worth noting that this set comprises ten observation sets comprising the observed input output behavior for single, double, and triple faults and for every circuit.
We conduct the experiments making use of an Apple iMac Pro (2017) computer setup with an Intel Xeon W 3 GHz ten-core processor, 128 GB DDR4 2666 MHz memory, and the up-to-date operating system macOS 10.14.6. For the theorem prover, we used clingo version 5.4.0. For the algorithm implementation, we relied on the programming languages Python 3.6 or Java 1.8. It is worth noting that there is a difference in the implementation for the programming languages. Whereas there is a direct interface to clingo from Python (see the previous study [18] ), the Java implementation has to call clingo using a command line shell interface provided in Java. For the comparison, we solely present the required runtime, including the total time to load, ground, and solve every ISCAS85 circuits as well as to save the evaluated diagnoses for later discussion. We limited search for diagnosis to 100 but did not make use of a specific time out. The rationale behind searching for 100 diagnoses is that, in practice, someone would definitely not be interested in a huge set of diagnoses.
To answer the first two questions, we carried out the experiments using only the correct behavior of each circuit. We show the obtained results in Table 3. There we summarize the minimum, maximum, average, and median runtime for each ISCAS circuit making use of the two clingo-based implementations and the mentioned Java implementation of a specialized diagnosis algorithm (HS-DAG), which has been previously discussed in the previous study. [17] It should be noted that we performed the experiments for HS-DAG using a time limit of 6000 s for double and triple fault diagnosis. Therefore, the comparison is limited to the minimum and maximum results for each circuit. Regarding the first question, i.e., whether ASP is feasible in practice, we can conclude the following. For single fault diagnosis, specialized algorithms seem to provide results faster on average and median. However, when it comes to double and triple faults, clingo provides results in a very much reasonable time almost similar to the runtime required for single fault. In addition, the required time for diagnosis using clingo seems to be sufficient for practical applications especially in cases where the number of components is less than 1000. Table 3. Run time in seconds for computing single-, up to double-, and up to triple-fault diagnoses for theorem prover clingo based on software solutions of Python, Java, as well as for HS-DAG (max diagnose time limit set to 6000.0 s for double-and triple-fault diagnosis). Regarding the second question, whether there is a runtime difference when using Python or Java, the results shown in Table 3 allow us to come up with the following observations. The difference of the median runtime of both implementations seems to be insignificant, although the Python API for clingo is more convenient to use. However, when considering the total computation time over all circuits, the Python version is 64% faster than the Java implementation. This time difference is mainly caused by finding double and triple faults for the specific circuit c7552. Hence, the provided Python API to clingo improves the overall runtime.
For answering the third and last questions, i.e., giving an estimation of the impact of using strong fault models on diagnosis using the ASP implementation, we run the benchmark circuits with stuck-at faults using our Python implementation. We depict the obtained results for single, double, and triple faults in Table 4. From there, it is interesting to note that the median runtime, except for circuit c7552 asking for double and triple faults, is reduced, when using strong fault models. This is also visible when summing up the required total diagnosis runtime over all ISCAS circuits that result in a time reduction of 44% for stuck-at faults. Hence, the use of strong fault models seems to improve the diagnosis time or at least does not necessarily lead to an increase. The underlying reason for this case maybe is that stuck-at faults somehow simplify computation, because they do not constrain input values but only set a particular output value of a component.
In summary, the experimental evaluation shows that ASP solvers such as clingo are feasible for practical diagnostic applications and even improve the overall diagnosis time in case of double and triple faults compared with specialized diagnosis algorithms. There is a difference of runtime considering

Conclusion
In this article, we focused on adding diagnostics functionality to intelligent agents. We argued that diagnosis capabilities are required especially in cases where an intelligent agent has to deal with unexpected situations or internal faults. To implement smart diagnostics, we suggested to come up with adding monitoring and diagnosis functionality to the overall system's architecture. The monitoring component is responsible for obtaining observations required by the diagnosis component for detecting failures and localizing faults, i.e., their root causes. We, furthermore, argued that model-based reasoning provides the right means for implementing smart diagnostics, allowing an intelligent agent to deal with root causes once identified. After outlining the foundations behind model-based reasoning, we presented an implementation of a diagnosis algorithm that can make use of ASP for computing minimal diagnoses up to a pre-defined size. In addition, we extended previous research and showed how fault models can be integrated. We also presented experimental results obtained using the state-of-the-art ASP solver for diagnosis. From the experimental results, we concluded that such ASP solvers can be effectively used for diagnosis of even larger circuits and compared with a specialized diagnosis algorithm provides solutions faster when considering double and triple faults. Even when using fault models, ASP provides a reasonable runtime. Future research will include providing adopting the approach for combining simulation models with diagnosis models. Moreover, we want also to clarify the question whether we can make use of machine learning for coming up with diagnosis models from simulation models in an automated fashion. The objective behind is to broaden the use of model-based diagnosis for different application domains not requiring additional modeling but utilizing other models such as simulation models in case of CPSs.