Beyond Dynamic Bayesian Networks: Fusing Temporal Logic Monitors with Probabilistic Diagnosis

As defined by Pearl [22], Bayesian Networks (BNs) are directed acyclic graphs that model causal relationships between variables. In this framework, the nodes represent the variables themselves, while the connecting arcs point from a cause to its direct effect. The probabilistic strength of these causal links is captured by conditional probabilities. The example below, also from [22], serves as a practical illustration of a BN in action.

Figure 1 shows a representative BN, where the complete joint probability distribution $p(x_1,x_2,x_3,x_4,x_5,x_6)$ is the product of the conditional probabilities of each proposition given its ancestors, Eq. (1).

The joint probability distribution could also be expressed with the following notation:

where ${𝒂}_j$ represents the set of ancestors of variable $x_j$, and $𝒙$ is the random vector containing all variables $x_1,\mathrm{\dots },x_n$ [23, 2]. For example, the term $p(x_4|x_1,x_2,x_3)$ becomes $p(x_4|{𝒂}_4)$.

Dependencies among propositions are described through the definition of sets of ancestors (or parents) and descendants (or children). For example, the set $\{x_1,x_2,x_3\}$ contains the ancestors of $x_4$, while $\{x_2,x_3\}$ contains the children of $x_1$. This structural model allows analysis over interventions, i.e., enable the computation of the joint probability density function (pdf) conditioned on some specific assumptions over a specific variable in the network [23]. Starting from the example in Figure 1, it is possible to evaluate the joint pdf given, e.g., $x_2$ has been defined True:

A key challenge in applying Bayesian Networks is the effort required to assess all conditional probabilities. Each node in the network needs a Conditional Probability Table (CPT) that defines its state based on every possible combination of its parents’ values, meaning the table’s size grows combinatorially with the number of parents. For instance, while we can represent an intervention like forcing $X_2=1$ by simply removing the edge from its parent $x_1$ (as its state no longer depends on $x_1$, see Eq. (3)), the initial construction of such dependency tables for networks with many interconnected nodes remains a significant practical obstacle.

The real-time R2U2 (Realizable, Responsive, and Unobtrusive Unit) has been developed to continuously monitor system and safety properties of an aerospace system. R2U2 has been implemented as an FPGA configuration [10]. and a software component. Hierarchical and modular models within this framework [27, 28] are defined using Metric Temporal Logic (MTL) [13] and mission-time Linear Temporal Logic (LTL) [25] for expressing Boolean formulas and temporal properties. In the following, we give a high-level overview over the R2U2 framework and its implementation. For details on temporal reasoning, its implementation, and semantics the reader is referred to [25, 10, 28].

Figure 3 gives a high-level overview of the architecture for our approach. Input signals $S_t$, which are obtained at time point $t$ from sensors, software sensors, the system status, and outputs of our diagnostic BN are first going through a signal processing stage, where the values, usually floating point numbers, are scaled and subjected to thresholding to obtain Boolean values. In our architecture, the thresholds and range limits are model-based and assumed to be fixed. For example, a floating point signal $U_{batt}$ might be thresholded using to obtain the Boolean value Ubatt_low. Signal processing is carried out with a fixed basic rate, e.g., 10Hz.

The vector of Boolean values $B_t$ for time $t$ are now input to the R2U2 monitoring engine. Here, formulas in past-time and future-time logic are evaluated to yield Boolean or 3-valued (see Section 3.5.1) valuations $V_t$ of each of the formulas at $t$. These outputs comprise the output of our diagnostic system and are also fed into the diagnostic BN.

For example, the formula ${\mathrm{\square }}_{[60s]}\text{Ubatt\_low}$ could correspond to a failure-mode “battery-too-weak-unusable”. On the other hand, a formula ${\mathrm{\square }}_{[2s]}\text{Ubatt\_low}$ would filter out short drops or glitches of the battery voltage, and the result would be used as a value for an observable sensor node in the BN.

At each point in time $t$, the BN is evaluated and posterior probabilities are calculated. These probabilities for selected nodes correspond to the presence of failure modes or can correspond to component health; these values are direct outputs for our diagnosis system.

These posterior probabilities can also provide valuable information, when considered over time: for example, knowing if subsystem $C$ has a poor health for an extended period of time. Therefore, selected values are fed back into the signal processing to be able to formalize such temporal properties.

Our proposed diagnostic architecture is purely model-driven and contains no machine-learning elements. The process steps for configuring and tailoring our tool is outlined in Figure 4. We derive diagnostic information from a comprehensive suite of models that are developed during the design phase of a complex and potentially autonomous system (see Table 1 for an overview). Most notably, functional decomposition models, fault trees, and the outputs of a Failure Mode and Effects Analysis (FMEA) are used to automatically construct the diagnostic Bayesian Network. The probabilities for the Bayesian transitions are informed by a combination of metrics, including Mean Time To Failure (MTTF) and Mean Time Between Failures (MTBF), as well as operational conditions, system health, and subject matter expert (SME) expertise.

These models, together with system and component requirements, Concept of Operations (ConOPS), and safety/performance requirements are used to define the logic and temporal monitors for R2U2. In the following sections, we describe in detail how the BN and temporal monitors are constructed, before we discuss a realistic example.

To develop an effective system-level diagnosis framework under uncertain conditions, we integrate information from a Failure Mode and Effects Analysis (FMEA) with a Bayesian Network (BN). This process unfolds in two main stages: first, we construct the graphical structure of the BN, and second, we define its conditional probability tables (CPTs) which quantify the relationships between different failure events.

The initial stage involves building the network’s structure by translating the qualitative FMEA data into the BN’s components. Then systematically convert the identified causes, failure modes, and effects from the FMEA into nodes within the network. This includes creating “observable” nodes that represent real-world sensor data – such as a high-temperature reading – which are critical for identifying and isolating the root cause of a failure. The network is then assembled by drawing directed arcs that reflect the causal logic from the FMEA, pointing from causes to their resulting failure modes and from failure modes to their ultimate effects. A simple example of a BN structure build from FMEA of an UAV electric powertrain is shown in Fig.5 for illustration.

With the Bayesian Network (BN) structure in place, we then assign probabilities to each node. First, root nodes (those with no parent nodes) are given prior marginal probabilities. Next, every other node is assigned a conditional probability based on its parent nodes, using information derived from the FMEA. To determine these values, we can draw from several sources, including historical failure data, the expertise of engineers, or established techniques such as maximum entropy theory [11].

Once the BN is fully defined, it can be used to detect and localize a fault within a complex system by turning observable nodes to True or False. The process starts when an observable evidence node, or “symptom,” is triggered – for example, when a sensor value exceeds a set threshold. This new evidence is fed into the network, which then uses Bayesian inference to update the probability of every potential root cause. The cause that emerges with the highest failure probability is identified as the source of the fault. We will address potential complicating factors, such as environmental conditions and false alarms, in the next section.

The dependency among elements in FMEAs do not have to be restricted to deterministic relationships in BNs [2], and this property intrinsically enhances the modeling of the diagnostic system. Let us consider, for simplicity, a fault event $f$ with two root causes, its ancestors, $x_1$ and $x_2$. Table 2 is the conditional probability table of the model, where probabilities are defined through three binary subscripts $i,j,k\in \{0,1\}$. The term $p_{k|ij}$ defines the probability of the outcome $k$ given values $i,j$, with $k$ referring to the fault event $f$ and $i,j$ referring to its ancestors $x_1$ and $x_2$. For example, $p_{1|\mathrm{0\hspace{0.17em}0}}$ is the probability that $f=1$ given both ancestors $x_1,x_2$ are 0 (or False).

The fault event may happen, with low probability, because of external causes or unknown events not described by its ancestors. Such external forcing was called Common Cause Failures in [2], and following that idea, $p_{1|\mathrm{0\hspace{0.17em}0}}\ge 0$, and so $p_{0|\mathrm{0\hspace{0.17em}0}}=1-p_{1|\mathrm{0\hspace{0.17em}0}}$. On the opposite side of the spectrum, the fault event may not happen even if both ancestors are activated (true). This option describes the ability of a system to work partially or reconfigure, [2], or describes a statistical relationship between the three elements, suggesting that root causes do not deterministically trigger the failure, so . As a result, the two ancestors may occur without triggering the fault event, so $p_{0|\mathrm{1\hspace{0.17em}1}}\ge 0$ and $p_{1|\mathrm{1\hspace{0.17em}1}}=1-p_{0|\mathrm{1\hspace{0.17em}1}}$. Different ancestors may influence the fault event in different ways, e.g. according to the severity of the root cause. This properties can be easily embedded in the network by assigning different values to the probabilities conditioned over $\{X_1=1,X_2=0\}$ and $\{X_1=0,X_2=1\}$.

In addition to the cases of failures induced by external variables or prevented system reconfiguration, the BN should also account for the performance of the measuring and/or detection system. In the proposed architecture, the evidence used to perform inference over the network is collected through sensors that measure variables connected (directly or indirectly) to the fault event we aim to detect. The sensor performance or, similarly, the ability of the detection system to identify anomalous sensor data, should be embedded in the estimation of the CPT values. Reconnecting to the previous example, therefore, the element $p_{0|\mathrm{0\hspace{0.17em}0}}$ in Table 2 should account for false alarm rates, and $p_{1|\mathrm{1\hspace{0.17em}1}}$ should include, on top of any statistical relationship between the elements, the probability of mis-detection.

Different BN inference algorithms can be used to compute a posterior probabilities. These algorithms include junction tree propagation [14, 12, 29] conditioning [8], variable elimination [17, 30], stochastic local search [21, 19], and arithmetic circuit evaluation [9, 5].

We select arithmetic circuit (AC) evaluation as our inference algorithm, which compiles our diagnostic BN into an arithmetic circuit. Especially for real-time aerospace systems, where there is a strong need to align the resource consumption of diagnostic computation to resource bounds [20, 18] algorithms based upon arithmetic circuit evaluation are powerful, as they provide predictable real-time performance [5]. An arithmetic circuit is a directed acyclic graph (DAG) in which the leaf nodes $\lambda$ represent parameters and indicators while other nodes represent addition and multiplication operators. Figure 6 shows a small BN and its corresponding AC.

Posterior marginals in a Bayesian Network can be computed from the joint distribution over all variables $X_i\in 𝒳$:

where ${\theta }_{x|𝐮}$ are the parameters of the Bayesian network, i.e., the conditional probabilities that a variable $X$ is in state $x$ given that its parents $𝐔$ are in the joint state $𝐮$, i.e., $p(X=x|𝐔=𝐮)$. Further, ${\lambda }_x$ indicates whether or not state $x$ is consistent with BN inputs or evidence. For efficient calculation, we rewrite the joint distribution into the corresponding network polynomial $f$ [9]:

An arithmetic circuit is a compact representation of a network polynomial [7] which, in its in-compact form, is exponential in size and thus unrealistic in the general case. Hence, answers to probabilistic queries, including marginals and most probable explanations (MPEs), are computed using algorithms that operate directly on the arithmetic circuit. The marginal probability (see Corollary 1 in [9]) for $x$ given evidence $e$ is calculated as

where $Pr(𝐞)$ is the probability of the evidence $𝐞$. In a bottom-up pass over the circuit, the probability of a particular evidence setting (or clamping of $\lambda$ parameters) is evaluated. A subsequent top-down pass over the circuit computes the partial derivatives $\frac{\partial f}{\partial {\lambda }_x}$.

To evaluate the developed Bayesian Network (BN), we utilized the SamIam software package [6]. SamIam is a powerful, Java-based tool from UCLA that provides a comprehensive environment for modeling and reasoning with BNs. It includes a graphical user interface for building network models and a robust reasoning engine. This engine supports various critical functions, including classical inference, parameter estimation, sensitivity analysis (to assess how changes in one node affect the entire network), and the computation of Most Probable Explanations (MPE) [9, 7].

We applied this framework to the powertrain BN, as shown in the schematic of Fig. 7. In our evaluation, the sensor nodes are observable and clamped to their current values. The resulting posterior probabilities of the other nodes are then calculated. For instance, in the scenario depicted, all sensor readings are nominal except for an abnormal motor current, $I_m$. The BN correctly infers a high posterior probability for the “bad motor bearing” fault mode, identifying it as the likely root cause. It is important to note that this specific example does not incorporate temporal monitors.

R2U2 monitors are used in our architecture to pre-process sensor signals (e.g., by thresholding) and to watch conditions in sensor signals and outputs of the BN over time. In order to allow simple signal processing, the input language for R2U2 can, in addition to Boolean Variables, contain arithmetic expressions, like $U_{batt}>21.0V$.

For diagnostic purposes, there exist a number of different kinds of monitor patterns, including (see also Table 3):

Thresholding:

such monitors perform simple signal processing tasks and determine if the current signal value is above or below a certain threshold, or is within a given range.

Persistency:

a condition is considered to be persistent if it is consecutively true for at least $n$ time steps: ${\mathrm{\square }}_{n}C$. Such formulas are used to filter out short dropout or nuisance signals.

Conditions:

failure conditions might be only considered, when certain conditions hold, e.g., when the system is in a specific mode.

Transient blocking:

upon a change in the system (e.g., a mode change), a failure condition is blocked during a certain temporal interval

Occurrence:

these types of monitors can determine if a signal or event occurs more than $n$ times within a given interval. This type of monitors can be used to trigger events based upon failure rates, e.g., there should not be more than 3 ill-formed data packets within a 10s interval.

Expectations:

these kinds of formulas can be used to monitor if certain events occur before, during, or after a certain triggering event or condition. E.g., after touchdown, the engine RPM should be within 30 seconds below 10$s^{-1}$.

Each of the variables of these formulas can be Boolean’s obtained by thresholding sensor signals or the posterior probabilities of the failure-mode nodes of the diagnostic BN. This capability allows use to write monitors, which depend on diagnoses. E.g., if the health of a lidar sensor has been poor for at least the last minute, then only large measurement errors causes the triggering of a failure mode. Such formulas can be used to customize the diagnosis system based upon current diagnostic results and health status. If a subsystem has been diagnosed with a poor health, it might be necessary to tolerate larger error margins in order to avoid cascading of failure conditions.

We illustrate our approach with a simple model of an electric powertrain for a UAS system. As shown in Figure 8A, the system consists of a li-ion battery $B$, the brushless dc motor $M$ (only one shown here), and the electronic speed control $ESC$. For each of the components, we measure temperature $T$, voltage $V$ and current $I$. In the high-fidelity simulator, which uses physical and electro-chemical models, measurements are obtained in 10 second intervals. Figure 8B shows the measurement signals which are typical for a nominal situation, where between $t=900s$ and $t=1800s$ the motor load is increased, leading to increased currents $I$ and a slight rise in battery temperature. The battery voltage slowly decreases as the battery discharges as load decreases based on operational modes. Toward the end of the scenario, the battery is near-empty and discharges very quickly.

In the nominal scenario, voltages and currents at each component are the same. As shown in Figure 5, our diagnostic BN has input nodes for temperatures, currents, and voltages, and is capable of diagnosing battery-related issues (thermal runaway, low state-of-charge, low state-of-health),, motor issues (bearing problems and change in the resistance of the motor winding), as well as in the electronic controller (power MOSFET electronics, or pulse-width-modulation (PWM) issues).

Figure 9 shows the original nominal signals for the battery, their discretizations with R2U2, as well as the posterior probabilities for the SOC and SOH nodes. Most significantly, a is considered low battery voltage (V_batt_low) and V_batt_nom is a battery voltage between 20V and 26V. The figure shows that with lower voltage through increased load, and through discharge, the BN nodes for SOC and SOH change, indicating a low state of charge. Toward the end of the scenario, the battery is drained and the voltage goes off-nominal. For this scenario, a simple BN is sufficient and no temporal operators are necessary. In the next scenario, however, we need to deal with noisy signals: the battery voltage signal can have drop-outs of up to 30 seconds. These dropouts, however, should not count toward a highly discharged battery. In our framework, we subject the battery voltage signal to the R2U2 formula

The noise in Figure 9 has been eliminated properly. If we want to filter out longer-lasting periods of low voltage, like the time between $t=900s$ and $t=1800s$ in Figure 8B, the R2U2 formula just needs to be adjusted; the additional memory overhead for processing the temporal formula is minimal (just a ring buffer for 90 integer variables). This is in stark contrast to using a dynamic BN, which would require to replicate the basic network 90 times.

Figure 10 illustrates a diagnostic scenario in which the order of events is important. Initially, a flight is operating under nominal conditions. After some time, the motor current ($I_m$) begins to increase while the voltage ($V_m$) stays constant. In response, the Bayesian Network (BN) diagnoses a potential issue with the motor’s bearing or winding. The resulting increase in friction and current then causes the motor temperature ($T_m$) to rise. Once $T_m$ surpasses a critical threshold, the posterior probability for both “bearing” and “winding” failures becomes very high. This clearly points to a motor malfunction, but a static BN that fails to consider the sequence of events cannot differentiate between these two failure modes, leading to an ambiguous diagnosis.

In our framework, we add a past-time temporal formula to the output of the BN:

Only if an issue with the motor bearing has been flagged continuously for at least 100s and then, within 10 seconds, the bearing and the winding issues are flagged at the same time for at least 20 seconds, we can disambiguate the situation and infer that the bearing issue is the root cause. The 10 second grace time of the temporal “S” (Since) operator is used to minimize transient effects observed due to change in operational modes.

The symmetric R2U2 formula for the winding issue would look like:

Figure 10 shows traces for both scenarios. Although a single DBN would be capable of modeling this situation, the complex temporal dependencies would require a large and complex DBN.