My main research topic is the diagnosis of discrete-event systems. The basic idea is the following. Consider a system (for instance a machine, such as a computer, a car, a space robot, or machine in a factory, etc.) which performs some actions. The system is subject to faults (such as short-circuit, leaking, break of a component, etc.) which leads to an uncorrect behaviour of the system. The goal is to use the observations (alarms generated by the system, informations provided by sensors, etc.) on the system find out what happened on the system.
More precisely, I am interested in discrete-event systems. Such systems are so that their behaviour is not continuous but can be modeled as a discrete evolution (by events). A set of behaviours on such a system can be represented by an automaton. For instance, the model is often an automaton (or an equivalent representation). I often define the diagnosis as the computation of all the possible behaviours on the system consistent with the observations. This can also be represented by an automaton. The problem is quite well defined, and the main issue is the complexity which is exponential in the number components in the system.

Using independency

The computation of all the behaviours on the system in particularly interesting for several reasons. First, this algorithm is general: the goal of the diagnosis is sometimes to get the current state of the system, or the number of faults that occurred; a unique algorithm is able to answer these questions. Second, in case a lot of queries are asked on the system, the computation of all the behaviours needs to be done only once, and the computation of the diagnosis is then simple.
However, the automaton that represents these behaviour is of size exponential in the number of component which is often impractically tracktable. Thus, Marie-Odile Cordier and I proposed the use of decentralised automata chain. The goal is to benefit from independent (concurrent) behaviours to build the diagnosis of subsystems of the system. Since all the subsystems eventually interact, we proposed to \emph{slice} the diagnosis period into small period to benefit from short-duration independences.
An interesting issue is this slicing, since the efficiency rely on the slicing. Another interesting point is the generalisation of this slicing: how to manipulate diagnoses of different subsystems on different (possibly overlaping) periods.

SAT techniques

Diagnosis can be seen as the computation of paths on the model of the system. SAT (satisfiability of classical propositionnal formulae) techniques already have been successfully used for similar AI problem such as planning or model-checking. Thus, using SAT for diagnosing discrete-event systems.
The reduction of the diagnosis to a satsifiability problem looks pretty simple, but issues are how to incrementally compute the diagnosis or use a decentralised computation.

Provide a unified modelling

Most of the people working on diagnosis of discrete-event systems use different modelling and hypotheses on the system. We have proposed, in the SuperCom project, to give a unified representation that can handle reconfiguration. This model should be available soon and so will be Java files.

Joint tree

In case the system is a tree, then the diagnosis of the whole system does not need to be computed: it is sufficient to check consistency bottom-up and then top-down to get all the local behaviours. Most of the systems are not tree-shaped, but it is possible to translate the system in a joint tree to get this shape.
This solution needs to be investigated, and the building of the tree might be dynamic to be as efficient as possible.

Extract useful information

Most of the systems are not theoretically diagnosable but can be easily diagnosed in most of the cases. However, there is no general simple method to find the diagnosis solution.
An issue is to extract from the model of the system and the observations the relevant information that is sufficient to find the solution. For instance, when diagnosing a component, it is sometimes required to compute what happenned in the components connected to this component.

Parallel diagnosis agents

The previous point is interesting in case of a unique (or a few) diagnosis query(ies). Considering that several diagnosis agent are working in parallel, one might expect that the agents reuse what has already been computed by the other agents. For instance, consider that an agent is diagnosing the behaviour of one component, and that information on the behaviour of another agent is required. If that component is diagnosed by another agent, it would be interesting to reuse what that agent has already computed.

Uncertain observations

In big systems (such as telecommunication systems), the delay of transmission of an observation is not null. Thus, the order of reception of the observations is not the same as the order of emission (a partial order is known). In case of on-line computation, an issue is that some buffered observations may be important to understand the last observations received. In some systems, some observations can be lost, sensors can fail, observations can be noisy, etc. I propose to represent the observations as an automaton (called observation automaton) rather than a sequence: each trajectory on the automaton is one possible sequence of emitted observations.
An interesting point with this vision is that the observation automaton can be seen as the diagnosis of the sensors and the communication channel of the observations (whose model is not necessarly in the same formalism than the one of the system). A question is then to unify this two tasks and to consider diagnosis in sequence for heterogeneous systems.