---
title: Storm Model Checker
url: https://www.emergentmind.com/topics/storm-model-checker
type: topic
---

# Storm Model Checker

Storm is a modern, extensible model checker for probabilistic systems, designed to provide high performance, modularity, and support for a diverse range of modeling formalisms, property logics, and analysis engines. Developed in C++ with a strong emphasis on separation of concerns between model representation, state-space construction, and solver backends, Storm is architected to accommodate cutting-edge research as well as industrial-scale verification tasks. Its ecosystem encompasses discrete- and continuous-time Markov chains, decision processes, automata, and domain-specific reliability models such as dynamic fault trees and stochastic Petri nets [1610.08713][2002.07080][1702.04311][2202.02829]. Storm also serves as the underlying verification platform for advanced synthesis and shield construction in stochastic game settings [2105.12588].

## 1. Supported Stochastic Models and Property Logics

Storm supports both deterministic and nondeterministic models across discrete and continuous time. The core model types are:

- **Discrete-Time Markov Chains (DTMCs):** $\mathcal{M} = (S, s_0, P, R)$, with $P: S \times S \to [0,1]$ a row-stochastic matrix [1702.04311][1610.08713].
- **Continuous-Time Markov Chains (CTMCs):** $\mathcal{C} = (S, s_0, Q, R)$, where $Q$ is a generator matrix [1702.04311].
- **Markov Decision Processes (MDPs):** $\mathcal{D} = (S, s_0, A, P, R)$, incorporating nondeterminism through actions and a scheduler [1610.08713][1702.04311].
- **Markov Automata (MAs):** Mixed discrete-continuous dynamics, supporting nondeterminism, probabilistic branching, and exponential delay [1610.08713][1702.04311].
- **Partially Observable MDPs, Generalized Stochastic Petri Nets (GSPNs), Probabilistic Programs (pGCL), Static and Dynamic Fault Trees (SFTs, DFTs):** Encoded via specialized frontends and reductions [1702.04311][2002.07080][2202.02829].

Reward structures $r: S \to \mathbb{R}$ or $r: S\times A \to \mathbb{R}$ extend these models for quantitative analysis.

Property specification in Storm uses:

- **PCTL** for DTMCs/MDPs; **CSL** for CTMCs/MAs, including reward extensions and conditional operators.
- Linear-time logic (LTL) via automata products.
- Multi-objective queries supported by linear programming and Pareto-curve construction [2002.07080].
- Counterexample generation and permissive scheduler synthesis using SMT and MILP [1610.08713].

## 2. Input Languages, Model Construction, and Architecture

Comprehensive input language support is a cornerstone of Storm:

- **PRISM language** (modules, guarded commands), parsed into ASTs [1702.04311][2002.07080].
- **JANI interchange format:** JSON-based universal model description [1702.04311][2002.07080].
- **Dynamic Fault Trees:** Galileo, Open-PSA, AltaRica, or DSL inputs parsed and normalized [2202.02829].
- **Stochastic Petri Nets (PNML), pGCL, and rPATL (via PRISM-games parser)** [1702.04311][2105.12588].

Storm’s architecture is modular, separated into frontends/parsers, model builders (sparse, symbolic, hybrid, exploration), engines, and plug-in solver interfaces. Model state spaces can be stored:

- **Explicitly:** as sparse matrices for small-to-medium models.
- **Symbolically:** as multi-terminal binary decision diagrams (MTBDDs), leveraging CUDD or Sylvan for structured or large models.
- **Hybrid:** combining symbolic and explicit representations dynamically.

The engine selection is user-configurable at runtime (`--engine sparse`, `--engine dd`, `--engine hybrid`, `--engine automatic`) [2002.07080]. Each engine forwards linear-, Bellman-, or game-solving requests to a library-wrapped backend.

## 3. Core Algorithms and Solver Infrastructure

Verification of PCTL/CSL and derived queries is uniformly reduced to classical numerical problems:

- **Reachability (DTMC/CTMC):** Solve $(I-P)x = b$ or $(Q-\lambda I)x = -b$ [1610.08713].
- **MDP analysis:** Value iteration (Bellman fixpoint), policy iteration, or linear programming [1702.04311][1610.08713].
- **CTMC Transient analysis:** Uniformization with Krylov or product-form solvers, truncating infinite sums at Poisson tail thresholds [1702.04311].
- **Parameter synthesis:** Symbolic rational elimination via the CArL library [1610.08713].
- **Game-based abstraction-refinement:** Reduces large/infinite MDPs to over/under-approximating stochastic games with counterexample-driven refinement [2002.07080].
- **Counterexample generation, multi-objective and sound/interval model checking:** Employ MILP, SMT, or interval-arithmetic backends for guarantees and strategy extraction [1610.08713][2002.07080].

Plug-in solver infrastructure includes Eigen, gmm++, built-in linear solvers, CUDD/Sylvan (MTBDD operations), Gurobi/GLPK (MILP), and Z3/MathSAT for SMT [1610.08713][2002.07080].

## 4. Domain-Specific Analyses: Dynamic Fault Trees and Reliability

Storm integrates advanced domain-specific symbolic and hybrid techniques for reliability analysis:

- **SFTs:** Purely BDD-based approach (Sylvan), exploiting multicore processing, variable ordering heuristics, and vectorized leaf evaluation [2202.02829].
- **DFTs:** Modular hybridization (“Dugan’s approach”)—detect maximal dynamic subtrees, analyze individually as CTMCs at one/many time-points, substitute with temporally-parametric basic events, and evaluate static shell via BDD [2202.02829].
- **Metrics:** Unreliability at arbitrary times, MTTF approximated by vectorized/parallel quadrature, minimal cut-set enumeration, Birnbaum importance computation, all scale linearly or sublinearly in number of time-points/model size due to SIMD and memoization.
- **Limitations:** Modular DFT analysis is only effective when dynamic components are bottom-heavy; BDD memory can spike with huge cut-set enumeration [2202.02829].

Empirical evaluation demonstrates that Storm-dft yields one to two orders-of-magnitude runtime improvements over pure CTMC or classic top-down modularization on benchmark suites comprising hundreds of fault trees [2202.02829].

## 5. Python API, Rapid Prototyping, and Extension Mechanisms

- **stormpy:** Python binding exposes Storm’s full model parsing, symbolic/numeric construction, and model-checking routines for rapid prototyping, with performance near that of native C++ [2002.07080][1702.04311].
- Minimal workflows: model parse $\rightarrow$ property parse $\rightarrow$ model build $\rightarrow$ model check $\rightarrow$ result query.
- **C++ API:** Templated design permits plugging in new arithmetic types, decision diagram libraries, or numerical solvers by modifying factory options.
- Developers can extend Storm by adding engines or interfaces, e.g., Tempest for 2½-player stochastic game algorithms [2105.12588].
- **Integration workflows:** Docker distribution for immediate usability; install-from-source permits choice among open-source and commercial backends [2002.07080].

## 6. Performance Benchmarks and Empirical Comparison

Storm exhibits competitiveness and often superiority across standard verification suites:

| Benchmark Source           | Tasks | Storm Successes | Competing Tool | Competing Successes | Comments                   |
|----------------------------|-------|-----------------|---------------|---------------------|----------------------------|
| PRISM suite                | 380   | 361             | PRISM         | 346                 | Storm up to $10^3\times$ faster [1702.04311] |
| QComp 2019                 | 96    | 84 (auto engine)| Best-of-rest  | <84                 | Oracle Storm solves all 96 [2002.07080]      |
| DFT/SFT suites             | >300  | All             | Scram/XFTA    | Mixed               | Storm-dft 10–100$\times$ faster [2202.02829] |

Evaluation on real-world reliability, cyber-physical, and protocol models confirms Storm’s architectural scaling benefits, especially for large/symmetric systems, multi-objective queries, and cost/reward-bounded properties [2002.07080][1610.08713][2202.02829].

## 7. Advanced Applications and Extensions: Synthesis and Shield Generation

Storm’s architecture serves as the basis for fully automated controller and shield synthesis in probabilistic and adversarial environments:

- **Tempest module:** Adds safety/mean-payoff stochastic game solvers for 2½-player (SMG) models, repurposing Storm’s modeling, engine, and linear algebra layers [2105.12588].
- **Shield types:** Pre-shield, post-shield, and optimal shield synthesis enabled via new property keywords and value-iteration extensions. Output strategies map state-action pairs to (permissible) safe choices.
- **Performance:** Tempest within Storm achieves sub-second synthesis for large-scale benchmarks, outperforming prior game-based toolchains by orders of magnitude [2105.12588].

## 8. Limitations and Future Directions

Storm’s present limitations include:

- Absence of native probabilistic timed automata support; users must supply LTL-automata encodings manually [1610.08713].
- Statistical model checking is restricted to DTMCs; continuous-time SMC planned [1610.08713].
- DFT modularization less effective when the model’s dynamic part dominates [2202.02829].
- Some symbolic-reduction heuristics (BDD variable reordering) remain experimental [2202.02829].
- Future developments include GPU-accelerated solvers, broader JANI integration, richer counterexample visualizations, and enhanced support for continuous parametric distributions [1610.08713][2002.07080].

Storm’s evolution is shaped by its open, modular, and research-driven codebase, rendering it both a practical verification workhorse and a testbed for formal analysis innovations in probabilistic verification [2002.07080][1610.08713][1702.04311][2202.02829][2105.12588].

Source: https://www.emergentmind.com/topics/storm-model-checker