Storm Model Checker

Updated 5 December 2025

Storm Model Checker is a high-performance tool for verifying probabilistic systems using discrete and continuous-time models.
It features a modular architecture with explicit, symbolic, and hybrid state-space representations for flexible analysis.
It integrates advanced solver backends and supports rapid prototyping and industrial-scale verification tasks.

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 (Dehnert et al., 2016, Hensel et al., 2020, Dehnert et al., 2017, Basgöze et al., 2022). Storm also serves as the underlying verification platform for advanced synthesis and shield construction in stochastic game settings (Pranger et al., 2021).

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 (Dehnert et al., 2017, Dehnert et al., 2016).
Continuous-Time Markov Chains (CTMCs): $\mathcal{C} = (S, s_0, Q, R)$ , where $Q$ is a generator matrix (Dehnert et al., 2017).
Markov Decision Processes (MDPs): $\mathcal{D} = (S, s_0, A, P, R)$ , incorporating nondeterminism through actions and a scheduler (Dehnert et al., 2016, Dehnert et al., 2017).
Markov Automata (MAs): Mixed discrete-continuous dynamics, supporting nondeterminism, probabilistic branching, and exponential delay (Dehnert et al., 2016, Dehnert et al., 2017).
Partially Observable MDPs, Generalized Stochastic Petri Nets (GSPNs), Probabilistic Programs (pGCL), Static and Dynamic Fault Trees (SFTs, DFTs): Encoded via specialized frontends and reductions (Dehnert et al., 2017, Hensel et al., 2020, Basgöze et al., 2022).

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 (Hensel et al., 2020).
Counterexample generation and permissive scheduler synthesis using SMT and MILP (Dehnert et al., 2016).

2. Input Languages, Model Construction, and Architecture

Comprehensive input language support is a cornerstone of Storm:

PRISM language (modules, guarded commands), parsed into ASTs (Dehnert et al., 2017, Hensel et al., 2020).
JANI interchange format: JSON-based universal model description (Dehnert et al., 2017, Hensel et al., 2020).
Dynamic Fault Trees: Galileo, Open-PSA, AltaRica, or DSL inputs parsed and normalized (Basgöze et al., 2022).
Stochastic Petri Nets (PNML), pGCL, and rPATL (via PRISM-games parser) (Dehnert et al., 2017, Pranger et al., 2021).

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) (Hensel et al., 2020). 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$ (Dehnert et al., 2016).
MDP analysis: Value iteration (Bellman fixpoint), policy iteration, or linear programming (Dehnert et al., 2017, Dehnert et al., 2016).
CTMC Transient analysis: Uniformization with Krylov or product-form solvers, truncating infinite sums at Poisson tail thresholds (Dehnert et al., 2017).
Parameter synthesis: Symbolic rational elimination via the CArL library (Dehnert et al., 2016).
Game-based abstraction-refinement: Reduces large/infinite MDPs to over/under-approximating stochastic games with counterexample-driven refinement (Hensel et al., 2020).
Counterexample generation, multi-objective and sound/interval model checking: Employ MILP, SMT, or interval-arithmetic backends for guarantees and strategy extraction (Dehnert et al., 2016, Hensel et al., 2020).

Plug-in solver infrastructure includes Eigen, gmm++, built-in linear solvers, CUDD/Sylvan (MTBDD operations), Gurobi/GLPK (MILP), and Z3/MathSAT for SMT (Dehnert et al., 2016, Hensel et al., 2020).

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 (Basgöze et al., 2022).
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 (Basgöze et al., 2022).
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 (Basgöze et al., 2022).

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 (Basgöze et al., 2022).

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++ (Hensel et al., 2020, Dehnert et al., 2017).
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 (Pranger et al., 2021).
Integration workflows: Docker distribution for immediate usability; install-from-source permits choice among open-source and commercial backends (Hensel et al., 2020).

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 (Dehnert et al., 2017)
QComp 2019	96	84 (auto engine)	Best-of-rest	<84	Oracle Storm solves all 96 (Hensel et al., 2020)
DFT/SFT suites	>300	All	Scram/XFTA	Mixed	Storm-dft 10–100 $\times$ faster (Basgöze et al., 2022)

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 (Hensel et al., 2020, Dehnert et al., 2016, Basgöze et al., 2022).

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 (Pranger et al., 2021).
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 (Pranger et al., 2021).

8. Limitations and Future Directions

Storm’s present limitations include:

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

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 (Hensel et al., 2020, Dehnert et al., 2016, Dehnert et al., 2017, Basgöze et al., 2022, Pranger et al., 2021).