BN Engine Overview

The Bayesian Network (BN) Engine provides steady‑state availability analysis for repairable systems and mission reliability analysis for non‑repairable systems. It uses probabilistic inference to compute exact results given your model’s assumptions and CPDs.

What is the BN Engine?

The BN Engine applies Bayesian Network theory to your YAML model to calculate the probability that each component (and the overall system) is UP. Dependencies (do, and, or, n_of_k) are encoded as a directed acyclic graph (DAG), and per‑node CPDs are derived from component parameters.

Key advantage

Provides mathematically exact inference (within the chosen model/CPDs), ideal for steady‑state analysis and “what‑if” exploration.

When to use the BN Engine

Best for

• Steady‑state availability analysis (repairable systems)
• Mission reliability analysis (non‑repairable systems)
• Impact analysis (identifying critical contributors)
• Root‑cause analysis (posterior cause when the system is down)
• “What‑if” scenario exploration
• Quick, repeatable validation of architectures

Limitations

• No explicit timing/dynamics (use MC Engine for time series and RTO distributions)
• Can be resource‑intensive for very large models (safety limits apply)
• Relies on steady‑state / mission‑time assumptions encoded in CPDs

Modes & assumptions

• Availability (repairable): Uses MTTF/MTTR (or prob) to build steady‑state CPDs for each component. Failure is exponential; repair is exponential or fixed time.

• Reliability (non‑repairable/mission mode): Set repair_enabled: false and provide simulation_time (mission time) in settings. For exponential failure, the CPD uses survival: P(UP) = exp(−t / mttf).

• Dependencies: One dependency type per target (do, and, or, n_of_k). An N-of-K target is UP when at least its required n distinct inputs are UP. Logical structure should be modeled on logical nodes; normal nodes use do: as the target relation.

Core capabilities

Availability calculation

Computes exact marginal P(UP) for each component and the root, honoring all dependencies and per‑node CPDs.

Impact analysis (Top contributors)

Ranks components by their contribution to overall unavailability/reliability loss to guide mitigation priorities.

Root‑cause analysis (posterior cause)

Given evidence that the system is DOWN, computes posterior probabilities of component failures (useful for incident triage).

Sensitivity explorer

Interactive “what‑if” tool to set evidence on components and observe availability deltas at the root and elsewhere.

Technical approach

• Dependency modeling: supports do, and, or, n_of_k with one type per target

• Distributions: failure exp; repair exp or fixed time delta

• Safety limits: resource guards and size limits protect the service on very large graphs

• Cross‑validation: results can be compared with the MC Engine for consistency

Next steps

For new users

• → BN Actions Guide

• → Simulation Settings

• → Creating Components

Advanced topics

• → Dependencies

• → Safety Limits

• → Results Interpretation

Distribution semantics

Failure times and timed latch completion delays are exponential. Repair times are exponential (default) or fixed (mttr_dist: delta, exactly MTTR hours). MTTF/MTTR are arithmetic means. No dispersion parameter is required. See duration distributions for supported fields and handling older models.

BN repair results are steady-state estimates. MC starts up and measures a finite horizon, so results need not match exactly. Without repairs, compare BN survival with MC reliability rather than MC time-averaged availability. Existing latch trigger/recovery differences also limit cross-engine comparisons.