Skip to content

Simulation Settings

Simulation settings control how both BN and MC engines analyze your models. These parameters significantly impact analysis accuracy, runtime, and resource usage.

Scope: Unless noted, settings apply to both engines. BN uses them for steady‑state/mission computations; MC uses them to drive temporal simulations and statistics.

Quick reference (YAML)

simulation_settings:
  simulation_time: 8760        # hours (1 year)
  repair_enabled: true         # allow repairs (steady-state availability)
  targets:
    availability: 0.999     # 0.999 default
    rto: 24                 # hours, 24 default
  simulation_runs: 1000     # Monte Carlo iterations (MC only)
  random_seed: 42           # optional; omit for non-deterministic
  • simulation_time and repair_enabled together define availability (repairable) vs mission reliability (non‑repairable) analysis modes.
  • Targets (target_availability, target_rto) drive breach flags in results.

Core time settings

Simulation Time

Default: 8760 hours (1 year)
Time horizon for analysis.

  • BN (repairable): Used for reporting metrics like expected downtime: downtime_h = (1 − availability) × simulation_time.
  • BN (mission / non‑repairable): With repair_enabled: false, CPDs use survival over mission time (e.g., exponential: P(UP) = exp(−t / mttf) where t = simulation_time).
  • MC: Sets the duration of each simulation run.

Common values
- 8760 = 1 year (default)
- 8760 = 10 years - 2190 = 1 quarter
- 730 = 1 month
- 168 = 1 week

Guidelines - Longer periods → more stable estimates; align with SLA reporting. - Consider component MTTF; horizons much larger/smaller than typical MTTFs may skew interpretation.

Target Availability (%)

Purpose: SLA threshold for breach analysis (applies to BN & MC outputs).
Set a number in 0.0–1.0 (e.g., 0.9999). Components below this threshold are flagged.

Common targets
- 0.999 (99.9%) → ~8.76 h downtime/year (deafult) - 0.9995 (99.95%) → ~4.38 h downtime/year
- 0.9999 (99.99%) → ~0.876 h (≈ 52.6 min)/year
- 0.99999(99.999%)→ ~0.0876 h (≈ 5.26 min)/year

Tips - Match actual SLA commitments.
- Use to prioritize mitigations.
- Leave unset if not applicable.

Target RTO (hours)

Purpose: Recovery Time Objective for MC analysis.
Used to compute how often recovery exceeds the target (RTO breach rate).

Guidelines - Base on business requirements.
- Consider both technical and organizational constraints.
- Interpreted in MC results as P(recovery_time > target_rto).

Repair mode settings

Enable Repair (repair_enabled)

Controls whether components can be repaired after failure.

Repair enabled (default)

  • Failures can be restored using MTTR (and its distribution).
  • Appropriate for steady‑state availability.
  • Reflects real operational behavior.

Repair disabled

  • Failures are absorbing (no repair).
  • MTTR is ignored.
  • Appropriate for mission reliability / one‑shot missions and conservative analyses.

Disable repair when…

  • Critical missions (space/defense), campaigns, or maintenance windows.
  • Safety cases and worst‑case assessments.
  • Systems where repair is not feasible within the horizon.

MC‑specific settings

Number of Simulation Runs (simulation_runs)

Default: 100

More runs → lower variance and tighter confidence bounds, but longer runtime.

Heuristics - 100 = quick smoke test
- 1,000 = standard analysis
- 10,000= higher precision
- 100,000+ = research/validation, high precision (heavy)

Trade‑offs - Diminishing returns beyond ~10,000 for many systems.
- Prefer multiple smaller experiments with different seeds to diagnose variability.

Random Seed (random_seed)

Set an integer to make results reproducible; omit for different sequences each run.

With seed - Reproducible runs (good for testing/regression).
- Easier comparison across changes.

Without seed - Better for exploratory sampling across many trials.
- Each run samples a new random stream.

Safety limits & performance

Latch‑X enforces guardrails to protect stability and fairness.

Need more headroom? See Safety Limits for upgrade paths and optimization tips.

Best practices

Getting started

  • Start with defaults—good for most cases.
  • Align simulation_time with SLA reporting.
  • Set target_availability / target_rto from real requirements.
  • Keep repair_enabled: true unless mission/non‑repairable.

Performance optimization

  • Begin with 100 MC runs; scale gradually.
  • Monitor safety limits before very large analyses.
  • Use random_seed for reproducible validation.

Common presets

Quick analysis

simulation_settings: simulation_time: 8760 simulation_runs: 100 repair_enabled: true targets: { availability: 0.999 }

Standard production

simulation_settings: simulation_time: 8760 simulation_runs: 1000 repair_enabled: true targets: { availability: 0.999 }

High precision (four nines)

simulation_settings: simulation_time: 8760 simulation_runs: 10000 repair_enabled: true targets: { availability: 0.9999 }

RTO targets

RTO vs MTD (business limit)

You don’t need a separate MTD field—keep using targets.rto. - To evaluate against your MTD, set targets.rto = MTD for that check (pass/fail at the business limit). - For day-to-day operations, keep targets.rto below your MTD (recommended), and review the recovery-time distribution in results to see how often you’d exceed the MTD. Rule of thumb: RTO ≤ MTD. ### Interpreting results Report both: - P(recovery > RTO) – operational risk against your target - P(recovery > MTD) – business risk at the hard limit

Next steps