Pueden considerarse dos tipos de comportamiento esperado del sistema con respecto al nivel de agua. El comportamiento esperado normal del sistema es mantener el nivel del agua dentro de algunos límites predefinidos. El comportamiento esperado anormal puede consistir en una inundación, es decir, la situación en la que el nivel es demasiado alto. Consideremos el último caso, estamos interesados en definir, descubrir y diagnosticar en fallo explícito en lugar de una anormalidad cualquiera. El fallo interesante es justamente inundación de agua. Describamos las diversas fases del procedimiento diagnóstico siguiendo el acercamiento propuesto.

Reconocimiento del fallo

Consideremos que la representación de estado parcial es una fórmula lógica de la forma  para el funcionamiento normal, donde el significado de es que el nivel del agua es superior a algún nivel denotado con low e inferior al denotado con high.

Consideremos ahora una fórmula que describe todos los estados (una situación en nuestra terminología, un conjunto de estados) en que ocurre una inundación. La fórmula puede ser de la forma . El problema de la detección del fallo consiste en verificar si el estado actual pertenece a la situación de fallo. Esto puede hacerse mediante emparejamiento de formulas con respecto a su generalidad; una fórmula más general describe un conjunto más grande de estados. Supongamos que el nivel denotado simbólicamente como very_high es superior al max (en la práctica éstos pueden ser simplemente números ordinarios). Sea la fórmula de estado actual, , donde  denota el resto de hechos verdaderos en el estado particular. Así en nuestro caso
 

De hecho, en cualquier estado descrito con la fórmula de la derecha, deben cumplirse las características de fallo especificadas por la fórmula ; el elemento crucial del chequeo consiste en verificar que .

Síntomas y grafo causal

La lista de síntomas considerada en el ejemplo es la siguiente; se estructura en diagnósticos elementales, síntomas intermedios y manifestaciones de fallo.

Manifestaciones,
 

m- se vierte agua fuera del deposito,
 

v1 - valve_open,
v2 - pump_off,
v3 - valve_stuck_in_open_position,
v4 - valve_open_by_control_signal,
v5 - pump_off_by_power_off,
v6 - pump_off_by_control,
v7 - pump_blocked,
v8 - pump_on_by_control,
v9 - valve_open_signal_operating,
v10 - pump_on_signal_from_level_sensor_operating,
v11 - pump_on_signal_from_control_system_operating,
v12 - power_off,
v13 - valve_open_signal_from_level_sensor_on,
 

d1 - valve_stuck_in_open_position_fault,
d2 -valve_open_control_signal_on,
d3 - level_sensor_on_when_level_too_high,
d4 - pump_on_by_control,
d5 - pump_broken_fault,
d6 - power_on.

Como puede verse, los síntomas intermedios incluyen observables (como v2, v5) y no-observables (como v3). Algunos de los síntomas pueden ser introducidos "artificialmente" para asegurar una presentación clara del grafo y distinguir entre tipos de nodos (e.g. v10, v11) para evitar mezclas de tipos. Los síntomas iniciales cubren los diagnósticos elementales que se refieren a los fallos de elementos (como d1, d3) así como señales de control defectuosos (como d2, d4) y condiciones externas (como d6).

El grafo causal se construye mediante el análisis de dependencias causales entre los síntomas y codificándolas en estructuras del nodo. La selección de nodos AND, OR y NOT ayuda a expresar la mayoría de los fenómenos comunes referidos a funciones lógicas. Los nodos NOT también representan negaciones de los síntomas. La estructura del grafo causal se presenta en la figura.

En la figura, los síntomas (nodos) verdaderos se marcan mediante círculos rellenados; los círculos vacíos denotan síntomas falsos o desconocidos. Después de la identificación del fallo, sólo el nodo marcado con m es verdadero. Cuando otras observaciones son accesibles, también v2 y d6 se marcan como verdaderos.

Razonamiento diagnóstico

Antes de empezar el análisis, propaguemos las observaciones a través del grafo. De hecho, sólo puede propagarse d6=verdad. Obtenemos v12=falso y v5=falso; esta información puede usarse por verificar la consistencia de los diagnósticos supuestos.

Empecemos el análisis de la manifestación de fallo. De hecho, la búsqueda se realiza hacia atrás, de arriba hacia abajo. Como se identifica el síntoma que significa el fallo m, se buscan las posibles razones para ello; la búsqueda se realiza al revés, es decir se buscan posibles explicaciones. Con respecto a nuestro modelo hay una causa conjunta posible,. v1=verdadero AND v2= verdadero. El procedimiento debe explicar recursivamente ambos síntomas encontrados. v2= verdadero es consistente con las observaciones (en otro caso habría una inconsistencia).

Para explicar v1= verdadero puede pensarse en dos hipótesis, v3=verdadero o v4=verdadero Continuemos por la última dejando la primero uno para una posible exploración posterior (en el algoritmo, se salva en la pila). De nuevo, para la explicación de v4=verdadero existen dos posibilidades; se supone que seleccionamos v13=verdadero y así debe cumplirse d3=falso; el proceso de explicar v1 se detiene aquí, ya que se ha llegado a un nodo inicial, que es un diagnóstico elemental. Las otras posibilidades de explicar v1=verdadero quedan para el posible uso posterior, ahora el problema es explicar v2=verdadero.

Para v2=verdadero hay tres posibilidades. Sin embargo, la primera, v5=verdadero es incoherente con las observaciones. Supongamos que se selecciona la segunda, v6=verdadero . La única explicación de v6=verdadero es v8=falso que es consistente con las observaciones. Y para explicar v8=falso debe asumirse que v10=falso y v11=falso. Esto implica d3=falso (tambien encontrado por otro camino), y d4=falso. El diagnóstico final es entonces , es decir, el sensor de nivel es defectuoso y no se proporciona ninguna señal de control para poner la bomba en marcha mientras el sistema esta funcionando. El posterior análisis del diagnóstico puede llevar al descubrimiento de un fallo fuerte (fallo del elemento, d3=falso), encontrando la señal de control a 0 (después de un análisis posterior del algoritmo del control para las condiciones específicas), y una condición operacional ya observada. Por supuesto, éste es sólo un diagnóstico potencial, y debe verificarse como tal, por ejemplo verificando el sensor de nivel y midiendo el valor de la señal de control. Es más, explorando las otras explicaciones alternativas de los síntomas pueden encontrarse otros diagnósticos, temporalmente pendientes. El conjunto de todos los posibles diagnósticos consistentes con las observaciones encontradas por el algoritmo es:
 

Sólo cuatro de ellos son diagnósticos mínimos (2,3,4 y 6) en el sentido de inclusión. Pero con respecto al subgrafo generado, los seis diagnósticos son soluciones diferentes. Para información, el problema anterior especificado sin las observaciones iniciales tiene 14 soluciones potenciales, y 6 de ellas son mínimos con respecto a la inclusión.

El resultado final es un diagnóstico, es decir, un conjunto de diagnósticos elementales, normalmente mínimo, tal que asumiendo que los componentes listados son defectuosos se genera una explicación del fallo observado con respecto al grafo causal. La obtención del diagnóstico se realiza encontrando un subgrafo solución que constituyen una explicación del fallo observado. Este subgrafo para el sistema del ejemplo se muestra en la siguiente figura. Los síntomas verdaderos se marcan con círculos rellenados.