Deploy Storm to Europe β Joost-Pieter Katoen π©πͺ (RWTH Aachen), the Probabilistic Model Checker for AI Safety and Reliability, on EU Infrastructure in 2026
Most software verification tools reason about whether a system is correct β whether it always reaches a safe state, never exhibits a prohibited behavior. But many real-world systems are not deterministic. A network protocol drops packets with probability p. A reinforcement learning agent selects actions according to a policy distribution. A medical device fails with a rate described by an exponential distribution. A nuclear plant's control system has components whose failure modes are quantified in a fault tree. For these systems, asking "is this property satisfied?" is the wrong question. The right question is: "With what probability?"
This is the domain of probabilistic model checking β formal verification of systems with quantitative uncertainty. And among the tools in this domain, Storm stands in a class of its own.
Storm is a modern probabilistic model checker developed at RWTH Aachen University π©πͺ β one of Germany's and Europe's leading technical universities β by Joost-Pieter Katoen and his group. Published at CAV 2017 ("A Storm is Coming: A Modern Probabilistic Model Checker"), Storm was built to address the scalability limitations of earlier tools while supporting a broader range of probabilistic formalisms than any predecessor. Today Storm is the reference implementation for probabilistic model checking in EU research and industrial verification.
Joost-Pieter Katoen and the RWTH Aachen Team
Joost-Pieter Katoen π©πͺπ³π± is the central figure behind Storm and one of the most influential formal methods researchers in Europe. He holds the Chair of Software Modeling and Verification at RWTH Aachen University π©πͺ β consistently ranked Germany's top technical university for computer science and engineering β and has held an honorary professorship at TU Munich π©πͺ. Born in the Netherlands π³π±, educated in the Dutch-German academic tradition, Katoen has spent his entire career at European institutions: University of Twente π³π±, Eindhoven University of Technology π³π±, and RWTH Aachen π©πͺ.
His contributions span probabilistic model checking, process algebra, stochastic systems, and theorem proving. He co-authored the definitive textbook Principles of Model Checking (MIT Press, 2008) with Christel Baier β a reference work used in formal methods courses across Europe and worldwide. His research group at RWTH Aachen has produced Storm, along with a generation of probabilistic verification researchers who are now faculty at European universities.
Arnd Hartmanns π³π± is now an Assistant Professor at the University of Twente π³π±. He was a core Storm developer and the primary author of the JANI model exchange format β the interchange language that allows probabilistic models to be shared between Storm, PRISM, and other tools. Twente π³π± is one of the EU's primary centres for embedded systems and formal verification research.
Tim Quatmann completed his PhD at RWTH Aachen and contributed fundamental algorithms to Storm, particularly for multi-objective model checking and long-run average properties on Markov decision processes.
Sebastian Junges is now a faculty member at Radboud University Nijmegen π³π±. He developed major components of Storm related to parametric Markov chains and parameter synthesis β probabilistic verification where model parameters (failure rates, transition probabilities) are symbolic rather than fixed.
Matthias Volk developed Storm's support for fault trees (DFT β Dynamic Fault Trees) and GSPN (Generalised Stochastic Petri Nets). His work connects Storm directly to reliability engineering applications in aerospace, automotive, and industrial automation β sectors with strong EU regulatory requirements under ISO 26262 and IEC 61508.
The Software Modeling and Verification group at RWTH Aachen is a joint EU research infrastructure. It receives funding from DFG (Deutsche Forschungsgemeinschaft π©πͺ), NWO (Dutch Research Council π³π±), and has participated in multiple EU Horizon research projects. Storm is an EU public-good research tool: open source (GPL-3.0), developed on European infrastructure, with no US institutional dependency.
How Storm Works: Probabilistic Model Checking
The Core Formalisms
Storm reasons about three primary probabilistic formalisms, each with a different expressiveness/complexity tradeoff:
Discrete-Time Markov Chains (DTMC) β states with fixed transition probabilities. From state s, the system moves to state s' with probability p(s, s'). The sum of outgoing probabilities from each state is 1. DTMCs model discrete probabilistic systems: randomised algorithms, probabilistic communication protocols, Markov chain Monte Carlo methods.
Markov Decision Processes (MDP) β states with both non-deterministic choices and probabilistic transitions. From state s, an agent (scheduler) first selects an action a, and then the system transitions probabilistically according to p(s, a, s'). MDPs are the mathematical model underlying reinforcement learning: a policy is a scheduler over the MDP. Properties quantified over MDPs have the form "for all schedulers / for the optimal scheduler, the probability of reaching a goal state is at most p."
Continuous-Time Markov Chains (CTMC) β states with exponentially-distributed time delays. Transitions fire at rates (not probabilities), and the time-to-next-transition follows an exponential distribution with rate Ξ». CTMCs model reliability and performance: component failure rates, service time distributions, queuing systems. Properties include "the probability of system failure within 100 hours is less than 10β»βΆ."
Property Specification: PCTL and CSL
Storm verifies properties specified in:
-
PCTL (Probabilistic Computation Tree Logic) β for DTMCs and MDPs. A PCTL formula can state: "with probability at least 0.99, the system eventually reaches a goal state" (
Pβ₯0.99 [F goal]), or "with probability at most 0.001, the system reaches an error state within 10 steps" (Pβ€0.001 [Fβ€10 error]). -
CSL (Continuous Stochastic Logic) β for CTMCs. A CSL formula can state: "the probability of being in a non-operational state at time t=1000 is at most 10β»β·" (
Pβ€0.0000001 [Fβ€1000 failed]). -
LTL (Linear Temporal Logic) β for MDPs with long-run properties. Storm can compute the maximum and minimum probability of satisfying any LTL formula over an MDP.
Storm's Algorithmic Core
What distinguishes Storm from earlier tools like PRISM is its architecture: Storm implements multiple model checking engines that can be selected based on problem structure, model size, and available hardware.
Sparse engine β the classic approach: represent the transition probability matrix as a sparse matrix and apply iterative numerical methods (value iteration, policy iteration, LP-based methods). Storm's sparse engine implements state-of-the-art sound value iteration variants that provide rigorous error bounds, addressing the well-known convergence problems of classical value iteration.
Hybrid engine β combines symbolic (BDD-based) state representation with explicit numerical computation. Models that are too large for sparse representation but have sufficient structure for BDD compression use the hybrid engine. This extends Storm's reach to models with hundreds of millions of states.
DD (Decision Diagram) engine β fully symbolic computation using multi-terminal BDDs (MTBDDs) or algebraic decision diagrams (ADDs). For models with extreme state-space symmetry, the DD engine can handle state spaces that are computationally unreachable with explicit methods.
Exact engine β for cases where floating-point errors are unacceptable. Storm integrates with exact rational arithmetic libraries to compute probabilities as exact rationals. This is critical for certification workflows where numerical results must be reproducible and verifiable.
Parametric Model Checking
One of Storm's distinctive capabilities is parametric model checking β reasoning about models where transition probabilities are not fixed values but symbolic expressions in parameters.
If a fault-tolerant system has component failure probability p (unknown, to be measured), parametric model checking computes the probability of system failure as a rational function in p. This function can then be evaluated for specific values of p, used to compute parameter synthesis (which values of p satisfy a given specification), or used in Bayesian inference workflows where p is estimated from observed failure data.
Parametric model checking is the tool of choice for safety case development when component failure rates have measurement uncertainty β the formal verification is not just about a single assumed failure rate but about the entire range of plausible values.
The EU AI Act Connection: MDPs and Reinforcement Learning Safety
The European Union Artificial Intelligence Act (EU AI Act), effective from August 2024 with high-risk AI obligations phasing in through August 2026, creates a direct demand for probabilistic verification.
Article 9 of the EU AI Act requires that high-risk AI systems implement a risk management system that quantifies residual risks to an acceptable level. For AI systems that operate as autonomous agents β navigation systems, medical decision support, autonomous industrial controllers β the underlying mathematical model is almost always an MDP: the agent takes actions, the environment responds stochastically.
Storm can verify MDP-based AI systems by answering questions like:
- What is the worst-case probability of a navigation system reaching an unsafe state (collision, out-of-bounds), over all possible adversarial environments?
- Does the optimal policy of a medical dosing agent guarantee that adverse outcomes occur with probability below the regulatory threshold, over all possible patient response distributions?
- Does a robotic assembly controller satisfy the production safety invariant with probability at least 0.9999, across all possible sensor failure scenarios?
These are not informal reliability estimates β they are formal proofs that specific probabilistic safety properties hold for the worst-case scheduler over the MDP. For EU AI Act Art. 9 compliance documentation, these results constitute auditable technical evidence of quantitative risk management.
The EU AI Act and GDPR Art. 25 overlap is also relevant to Storm: both require documented, proportionate technical controls for high-risk data processing. Probabilistic model checking of AI inference pipelines provides exactly this: machine-verified bounds on information leakage, decision boundary stability, and distributional robustness.
Input Languages: PRISM, JANI, Fault Trees, GSPNs
Storm accepts multiple input formats, making it the integration hub for probabilistic modeling:
PRISM language β the standard input format of the PRISM model checker (Birmingham/Oxford). Storm can load and verify any PRISM model, making it a drop-in replacement with significantly improved scalability. The PRISM Benchmark Suite (probabilistic model checking benchmark library maintained by the UK-EU research community) runs directly on Storm.
JANI (JSON-based Automata Network Interchange) β designed by Arnd Hartmanns et al. as a universal exchange format for probabilistic models. JANI models can be converted to/from PRISM, Modest, FAUSTΒ², and other tools. Storm's native JANI support makes it the universal verification backend for the EU probabilistic verification ecosystem.
DFT (Dynamic Fault Trees) β the standard notation for reliability engineering in aerospace (DO-178C), automotive (ISO 26262), and industrial control (IEC 61508). A fault tree specifies how component failures combine to produce system-level failures, with gates (AND, OR, Priority-AND, Functional DEPendency, Spare). Storm converts DFTs to CTMCs or MDPs and computes MTTF (Mean Time to Failure), steady-state unavailability, and transient failure probabilities. This makes Storm a formal verification tool for functional safety assessment.
GSPN (Generalised Stochastic Petri Nets) β the standard formalism for queuing systems, manufacturing workflow analysis, and network performance modeling. GSPNs convert to CTMCs, enabling Storm to verify performance and reliability properties of these models.
EU Industrial Applications
Automotive (ISO 26262 ASIL D): ISO 26262 Functional Safety for Road Vehicles requires probabilistic safety analysis at the system level. The ASIL D (highest integrity level) requires failure probability below 10β»βΈ per operating hour. Storm's DFT analysis with exact computation generates the certified numerical evidence required for ASIL D qualification packages. German OEMs (BMW, Daimler, Volkswagen) and Tier-1 suppliers (Bosch, Continental, ZF) operate R&D centres where ISO 26262 compliance analysis is performed β all within the EU.
Aerospace (DO-178C / ED-12C): European aerospace (Airbus π«π·π©πͺ, Dassault Aviation π«π·, Safran π«π·, MTU Aero Engines π©πͺ) uses probabilistic failure analysis for airborne software. The European Union Aviation Safety Agency (EASA, Cologne π©πͺ) enforces DO-178C/ED-12C compliance for avionics software. Storm's CTMC analysis of fault trees provides formal evidence for system-level safety assessments.
Energy (IEC 61508 SIL 3/4): Industrial control systems in EU energy infrastructure β nuclear (EDF π«π·, E.ON π©πͺ), grid automation (Siemens Energy π©πͺ, ABB π¨π/πΈπͺ) β require SIL 3 or SIL 4 certification. Storm's parametric model checking of failure rates provides formal PFD (Probability of Failure on Demand) and PFH (Probability of Failure per Hour) computations that are defensible in IEC 61508 certification audits.
Finance (DORA 2025): The EU Digital Operational Resilience Act (DORA), effective January 2025, requires financial institutions to quantify IT system failure probabilities. Storm's CTMC-based availability analysis (computing steady-state availability of critical financial infrastructure) provides formal evidence for DORA operational resilience assessments.
Deploying Storm on EU Infrastructure
Storm is distributed as a C++ compiled binary and Docker image. A typical deployment for a verification pipeline uses Storm's command-line interface:
# Verify a PRISM model: probability of reaching 'done' state
storm --prism model.pm --prop "P=? [F done]"
# Verify a JANI model with parametric analysis
storm --jani model.jani --janiproperty prop.jani --exact
# Fault tree analysis: MTTF computation
storm --dft fault_tree.dft --prop "T=? [F \"failed\"]"
# MDP verification: minimal probability of unsafe state
storm --prism agent.pm --prop "Pmin=? [F unsafe]"
A Storm deployment on sota.io for a verification pipeline:
FROM movesrwth/storm:stable
WORKDIR /verify
COPY models/ ./models/
COPY properties/ ./properties/
CMD ["storm", "--prism", "models/system.pm", \
"--prop", "P<=0.001 [F error]", \
"--engine", "hybrid"]
On sota.io, this container runs on German infrastructure β physically and legally inside the EU. For verification pipelines processing proprietary system models (automotive safety cases, financial system specifications, medical device behavioral models), EU data residency is not just a preference β it is a compliance requirement under GDPR Art. 25 and sector-specific regulations.
Storm's verification results β probabilistic bounds, counterexample traces, parameter synthesis outputs β constitute technical documentation for regulatory submissions. Running these computations on EU-sovereign infrastructure ensures the entire evidence chain (model, computation, result) is under EU legal jurisdiction.
See Also
- Deploy Java PathFinder to Europe β β Klaus Havelund π©π° (DLR Oberpfaffenhofen π©πͺ + NASA Ames), JVM explicit-state model checker: deadlock/race detection for concurrent Java AI systems β same EU AI Act Art. 9 audience, complementary (probabilistic vs. explicit-state)
- Deploy CPAchecker to Europe β Dirk Beyer π©πͺ (LMU Munich), the SV-COMP Champion
- Deploy UPPAAL to Europe β Kim Larsen π©π° (Aalborg University), Timed Automata Model Checker
- Deploy mCRL2 to Europe β Jan Friso Groote π³π± (Eindhoven), Process Algebra Verification
- EU AI Act Article 9 β Formal Verification for High-Risk AI Systems
Deploy Storm on sota.io β EU-native PaaS, free tier, GDPR-compliant infrastructure.