2026-04-05·10 min read·sota.io team

Deploy Astrée to Europe — Patrick Cousot 🇫🇷 (INRIA Paris / ENS), the Abstract Interpreter that Proved Airbus A380 Has Zero Runtime Errors, on EU Infrastructure in 2026

In 2003, engineers at Airbus faced a problem that no test suite could solve. The primary flight control software for the A380 — 132,000 lines of C — had to be certified to DO-178C Level A, the highest safety level in aviation. Level A certification requires evidence that no runtime error is possible: no division by zero, no buffer overflow, no arithmetic exception, no null pointer dereference, no unintended integer conversion. Testing could not provide this evidence. Testing only checks the paths it covers; for safety-critical avionics, the uncovered paths matter most.

The answer came from Astrée — a static analyser developed by Patrick Cousot and Radhia Cousot at INRIA Paris and École Normale Supérieure Paris, presented at PLDI 2003. Astrée analysed the entire Airbus A380 primary flight control software and reported zero false alarms: a machine-checked proof that no runtime error could occur in any execution, on any valid input, under any scheduling. The result made headlines in the formal verification community and placed France at the centre of the industrial abstract interpretation world.

Astrée is not a model checker that searches for counterexamples. It is a sound abstract interpreter: it computes an over-approximation of all reachable program states and proves that no state in that over-approximation can trigger a runtime error. If Astrée says "no alarms", the code is provably free of runtime errors — not merely free of the runtime errors a tester happened to trigger.

Patrick Cousot and Radhia Cousot: The Founders of Abstract Interpretation

Patrick Cousot 🇫🇷 is one of the most influential figures in programming language theory. Born in France, he studied at École Polytechnique and completed his doctorate at the Université Joseph Fourier in Grenoble. Together with his wife and long-time collaborator Radhia Cousot 🇫🇷, he introduced abstract interpretation in a landmark 1977 paper: Abstract Interpretation: A Unified Lattice Model for Static Analysis of Programs by Construction or Approximation of Fixpoints (POPL 1977).

The key insight: a program's semantics can be soundly over-approximated by computing fixpoints in abstract domains. Rather than tracking the exact set of reachable states (which is generally undecidable for infinite-state programs), abstract interpretation computes a safe over-approximation — a superset of all reachable states — using abstract lattice elements. If the over-approximation does not contain any error state, the concrete program has no errors. The over-approximation may miss some reachable states, but it cannot include states that are not reachable.

This theory, developed in Grenoble and then at ENS Paris (where Cousot was a professor from 1999 to 2012) and INRIA Paris (Institut National de Recherche en Informatique et en Automatique), became the mathematical foundation of industrial static analysis. Tools from Astrée to CPAchecker to CodeSonar to Clang's static analyser all rest on variants of the Cousot fixpoint framework.

In 2012, Patrick Cousot moved to New York University's Courant Institute. The Astrée project, however, remained rooted in France: the commercial version is maintained by AbsInt GmbH 🇩🇪 in Saarbrücken, Germany — a company founded by Christian Ferdinand and Reinhold Heckmann specifically to commercialise abstract interpretation tools for the European safety-critical industry.

The Astrée project team at ENS Paris included Antoine Miné 🇫🇷 (who developed the octagon domain, a key precision improvement used in Astrée), Xavier Rival 🇫🇷 (INRIA / ENS Paris, now at CNRS), Laurent Mauborgne 🇫🇷, and David Monniaux 🇫🇷 (CNRS, VERIMAG Grenoble — the same lab where CSP+TLA+ abstract interpretation research meets temporal logic).

The Mathematics of Sound Abstract Interpretation

Astrée's soundness rests on the Galois connection between concrete semantics (sets of machine states) and abstract semantics (lattice elements representing state approximations).

Abstract Domains in Astrée

Astrée's precision comes from a reduced product of multiple abstract domains, each capturing a different aspect of program state:

Interval domain: Each scalar variable x is approximated by bounds [lo, hi]. Simple, efficient, captures range properties.

/* Astrée proves: after loop, sum ∈ [0, n*(n-1)/2] */
int sum = 0;
for (int i = 0; i < n; i++) {
    sum += i;  /* Astrée: sum ∈ [0, INT_MAX], no overflow if n bounded */
}

Octagon domain (Antoine Miné 🇫🇷, ENS Paris, 2001 — SAS 2001): Constraints of the form ±x ± y ≤ d between pairs of variables. Captures correlations between variables that interval analysis misses. For flight control code with coupled sensor variables (e.g., roll_rate - pitch_rate ≤ 30), octagons make the difference between a false alarm and a proof.

Congruence domain: Constraints of the form x ≡ c (mod m). Captures alignment properties common in embedded code (e.g., array indices always even, byte offsets always divisible by 4).

Symbolic relational domain: Captures equalities and linear relationships between variables across procedure boundaries.

Trace partitioning (Xavier Rival 🇫🇷 + Laurent Mauborgne 🇫🇷, ESOP 2007): Rather than merging all execution paths at join points, Astrée can maintain separate abstract states for different trace prefixes — preserving precision where path-sensitivity matters, merging where it doesn't. This is the key technique that allowed Astrée to achieve zero false alarms on the A380 code without an explosion in analysis time.

Fixpoint Computation

For a program with loops, the abstract interpreter computes a fixpoint: starting from the initial state abstraction, it iterates the abstract transfer function (which approximates the effect of each statement) until the abstract state stabilises.

Concrete loop semantics:    S* = ⋃n f^n(S0)   (all reachable states)
Abstract fixpoint:          a* = lfp_⊤ F#       (least fixpoint above ⊤)
where F# is the abstract transfer function
and ⊤ is the top element (all states)

To guarantee termination, Astrée uses widening operators — abstract domain operations that accelerate convergence to a fixpoint by jumping to a safe over-approximation. The art in building a good abstract interpreter is choosing widening operators that are both sound (always over-approximate) and precise (don't over-approximate too aggressively). Astrée's widening strategy was tuned specifically for the floating-point and integer arithmetic patterns in Airbus flight control code.

Soundness vs. Completeness

Astrée is sound (no false negatives: if Astrée says "no runtime errors", there are none) but not complete (it may produce false alarms: Astrée may warn about a potential error that is actually unreachable in the concrete semantics).

The engineering challenge is minimising false alarms while maintaining soundness. For the A380 analysis, Astrée achieved zero false alarms on 132,000 lines of C — a result that required both the abstract domain refinements (octagons, trace partitioning) and domain-specific knowledge about the flight control architecture.

The Airbus A380 Story

The Airbus A380 analysis was performed by the ASTRÉE project in collaboration with Airbus (Toulouse, France 🇫🇷). The primary flight control software is written in C and compiled with AbsInt's CompCert 🇫🇷 (the formally verified C compiler) — creating a chain where:

The source C code is proved free of runtime errors by Astrée
The compilation is proved semantics-preserving by CompCert
The object code on the target processor is proved to meet timing requirements by AbsInt's aiT WCET analyser

This three-tool chain — Astrée + CompCert + aiT — represents one of the most rigorous software certification pipelines in commercial aviation. All three tools were developed or commercialised by French/German EU institutions (INRIA Paris 🇫🇷 / ENS Paris 🇫🇷 for Astrée and CompCert, AbsInt 🇩🇪 for commercialisation and aiT).

The key result from the 2003 PLDI paper and subsequent publications: Astrée analysed the A380 flight control software and found no runtime errors — proving that no division-by-zero, buffer overflow, null pointer dereference, or floating-point exception could occur in any execution. No human-written test suite could have achieved this result with the same guarantee.

Subsequent versions of Astrée have been applied to:

Airbus A350 flight control software
Airbus Military A400M transport aircraft
Alstom 🇫🇷 railway signalling (EN 50128 SIL 4)
French nuclear (EDF/CEA, IEC 61508 SIL 4)
Thales 🇫🇷 aerospace and defence (DO-178C DAL A)
Dassault Aviation 🇫🇷 (Rafale, Falcon business jets)

How to Use Astrée

The open-source Astrée prototype (originally released from ENS Paris) targets C programs with fixed-point arithmetic. The commercial Astrée from AbsInt handles full C99/C11 with floating-point arithmetic and is DO-178C Level A tool-qualified.

# Open-source prototype (for research and experimentation)
git clone https://github.com/AbsInt/astrée-oss.git
# or the academic version: build from the PLDI 2003 distribution

# Commercial Astrée (AbsInt, Saarbrücken) — contact AbsInt for licence
# absint.com/astree

# Astrée analyses C source directly:
astree -target arm-linux-gnueabihf \
       -entry-point main \
       -alarm-file alarms.txt \
       flight_control.c

# Expected output for verified code:
# VERIFICATION RESULT: No alarms
# (Proved: no runtime errors in any execution)

A minimal C program demonstrating the class of errors Astrée proves absent:

/* sensor_processing.c — Astrée proves no runtime errors */
#include <stdint.h>

#define MAX_SENSORS 8
#define SCALE_FACTOR 1000

/* Astrée domain annotation: input always in [-90000, 90000] millidegrees */
static int32_t sensor_values[MAX_SENSORS];
static int32_t filtered_output;

void process_sensors(int32_t raw_inputs[MAX_SENSORS], int n_active) {
    /* Precondition: 0 <= n_active <= MAX_SENSORS */
    /* Precondition: each raw_inputs[i] in [-90000, 90000] */
    
    int32_t sum = 0;
    
    for (int i = 0; i < n_active; i++) {
        /* Astrée octagon: i ∈ [0, n_active-1] → sensor_values[i] safe */
        sensor_values[i] = raw_inputs[i];
        
        /* Astrée interval: sum ∈ [-720000, 720000] → no overflow */
        sum += raw_inputs[i];
    }
    
    if (n_active > 0) {
        /* Astrée: n_active ∈ [1, 8] → no division by zero */
        int32_t avg = sum / n_active;
        
        /* Astrée: avg ∈ [-90000, 90000], SCALE_FACTOR = 1000 → result ∈ [-90000000, 90000000] → in int32 range */
        filtered_output = avg * SCALE_FACTOR / 1000;
    }
}

# Astrée analysis with range annotations
astree -entry-point process_sensors \
       -initial-value "n_active:[0,8]" \
       -initial-value "raw_inputs[*]:[-90000,90000]" \
       sensor_processing.c
# Output: No alarms — proved no array out-of-bounds, no divide-by-zero,
#                      no integer overflow, no unintended conversion

Docker Deployment for Continuous Integration

A production Dockerfile for a containerised Astrée static analysis service:

FROM debian:bookworm-slim

# AbsInt commercial Astrée requires a licence file
# Contact absint.com for academic and commercial licences
# Open-source prototype can be built from source

RUN apt-get update && apt-get install -y \
    build-essential cmake git \
    libgmp-dev libmpfr-dev \
    && apt-get clean

# For the AbsInt commercial version: copy licence + binary
# COPY astree-licence.dat /opt/astree/
# COPY astree-binary /usr/local/bin/astree

# For open-source prototype: build from source
RUN git clone --depth=1 https://github.com/absint/astree-oss.git /opt/astree-src \
    && cd /opt/astree-src \
    && make \
    && cp ./astree /usr/local/bin/astree

WORKDIR /workspace

COPY analyze.sh /usr/local/bin/analyze
RUN chmod +x /usr/local/bin/analyze

CMD ["analyze"]

#!/bin/bash
# analyze.sh — run Astrée + store results in sota.io PostgreSQL

for src in /workspace/src/*.c; do
  name=$(basename "$src" .c)
  
  # Run Astrée abstract interpretation
  result=$(astree \
    -entry-point main \
    -target arm-linux-gnueabihf \
    -alarm-file /tmp/alarms_${name}.txt \
    "$src" 2>&1)
  
  alarm_count=$(cat /tmp/alarms_${name}.txt 2>/dev/null | wc -l || echo "0")
  
  if [ "$alarm_count" -eq 0 ]; then
    verdict="PROVEN_SAFE"
    detail="No runtime errors in any execution (sound proof)"
  else
    verdict="ALARMS"
    detail="$(cat /tmp/alarms_${name}.txt | head -5)"
  fi
  
  # Store in EU PostgreSQL on sota.io — GDPR-compliant, no US Cloud Act
  psql "$DATABASE_URL" -c "
    INSERT INTO static_analysis_results (
      component, analyser, verdict, alarm_count, detail, timestamp
    ) VALUES (
      '${name}', 'astree-abstract-interp', '${verdict}',
      ${alarm_count}, \$detail\$${detail}\$detail\$, NOW()
    ) ON CONFLICT (component, analyser) DO UPDATE SET
      verdict = EXCLUDED.verdict,
      alarm_count = EXCLUDED.alarm_count,
      detail = EXCLUDED.detail,
      timestamp = EXCLUDED.timestamp;"
  
  echo "=== ${name}: ${verdict} (${alarm_count} alarms) ==="
done

# Deploy to sota.io
docker build -t astree-analysis-service .
docker push registry.sota.io/your-project/astree-analysis-service

curl -X POST https://api.sota.io/v1/projects/YOUR_PROJECT_ID/deploy \
  -H "Authorization: Bearer $SOTA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"image": "registry.sota.io/your-project/astree-analysis-service"}'

Analysis results — alarm reports and safety proofs — stored in EU-jurisdiction PostgreSQL on German infrastructure. No Cloud Act exposure.

Industrial Relevance: EU Safety-Critical Systems

Avionics: DO-178C Level A

Astrée is the only commercially available static analyser with DO-178C Level A tool qualification for absence of runtime errors in C. AbsInt's tool qualification documentation satisfies the DO-178C DAL A requirements for static code analysis tool independence.

For Airbus 🇫🇷 (A380, A350, A400M), Thales Avionics 🇫🇷, Safran Electronics 🇫🇷, and Dassault Aviation 🇫🇷 teams working under DO-178C DAL A:

No false negatives: Astrée's soundness guarantees no missed runtime errors — if it passes, the code is provably safe
Zero-alarm campaigns: Like the original A380 analysis, modern Astrée supports annotation-driven alarm elimination to achieve zero false alarms on verified codebases
Tool qualification independence: AbsInt's DO-178C qualification documentation allows Astrée to serve as a verification tool at the highest assurance level

Railway: EN 50128 SIL 4

For Alstom 🇫🇷, Siemens Mobility 🇩🇪, Thales Rail 🇫🇷, and Stadler 🇨🇭 developing ETCS onboard units and interlocking controllers under EN 50128 SIL 4:

Astrée's absence-of-runtime-error proof satisfies EN 50128 Table A.14 (Static Code Analysis) and Table D.8 (Software Metrics)
Proven at SIL 4: the highest railway software safety level (ETCS, ATC, signalling logic)
French nuclear via EDF/CEA: IEC 61508 SIL 4 for instrumentation and control systems in French nuclear power plants

IEC 61508 SIL 3/4

For European process industry manufacturers — Endress+Hauser 🇩🇪, Pepperl+Fuchs 🇩🇪, Wago 🇩🇪, Phoenix Contact 🇩🇪 — IEC 61508 Part 3 requires formal verification evidence for safety functions. Astrée's soundness satisfies the "formal methods" requirement when the analyser is configured with appropriate domain annotations and the absence-of-alarms result is documented.

EU Regulatory Context

EU Cyber Resilience Act (CRA) 2027

The CRA requires manufacturers to demonstrate "state of the art" security for products with digital elements. Astrée provides certificates for the most common embedded C vulnerabilities:

CWE-190 (Integer Overflow): Astrée's interval domain proves all arithmetic stays within bounds
CWE-125 (Out-of-Bounds Read) / CWE-787 (Out-of-Bounds Write): Astrée's octagon domain proves array indices stay within allocation
CWE-476 (Null Pointer Dereference): Astrée's pointer analysis proves dereferences are always valid
CWE-369 (Division by Zero): Astrée proves divisors are always non-zero

An Astrée "no alarms" result on a CRA-regulated embedded C product directly contributes to the technical documentation package required for EU market access.

EU AI Act Article 9: Risk Management Systems

For high-risk AI systems with embedded C inference engines — ADAS (Annex III §3), medical devices (Annex III §5), industrial control (Annex III §6) — Astrée provides:

Memory safety proofs for C inference engines: buffer overflows impossible, null pointer dereferences impossible
Arithmetic safety proofs for neural network layers: integer overflow absent in fixed-point inference pipelines
No false negatives: unlike fuzzing or testing, Astrée's proof covers all execution paths

The EU AI Act conformity assessment requires evidence for "all reasonably foreseeable risks" — a formulation that aligns naturally with Astrée's all-path soundness guarantee.

Astrée's data-flow analysis can verify that personal data processing code does not escape its intended scope: a range invariant on a loop counter proves that a batch processing loop cannot silently access records beyond the consented dataset. This is a formal "data minimisation by design" evidence trail under GDPR Art. 25.

The EU Abstract Interpretation Ecosystem

Astrée sits at the centre of a French-German abstract interpretation ecosystem that has no equivalent elsewhere:

Tool	Institution	Approach	Strength
Astrée	INRIA Paris 🇫🇷 / AbsInt 🇩🇪	Sound abstract interpretation	Zero runtime errors, Airbus-grade
Frama-C/Eva	CEA LIST 🇫🇷 + INRIA 🇫🇷	Abstract interpretation (Eva plugin)	C plugin platform, open-source
CPAchecker	LMU Munich 🇩🇪	Value analysis + predicate abstraction	SV-COMP, Linux kernel
CompCert	INRIA Paris 🇫🇷 / AbsInt 🇩🇪	Formally verified C compiler	No compiler-introduced errors
aiT WCET	AbsInt 🇩🇪	Abstract interpretation (timing)	Worst-case execution time for DO-178C

AbsInt 🇩🇪 (Saarbrücken) is unique in commercialising both Astrée (absence of runtime errors) and CompCert (absence of compiler errors) and aiT (absence of timing violations) — a complete formal evidence stack for DO-178C Level A certification from source code to object code timing.

The French institutional lineage: INRIA Paris (national research institute) + ENS Paris (grande école, Cousots' lab) + CNRS (national research centre, Monniaux/Rival) = the same ecosystem that produced Coq/Rocq, Why3, Alt-Ergo, Frama-C, and CompCert. Abstract interpretation and proof assistants grew from the same Paris mathematical tradition.

Deploying an Astrée Analysis Pipeline on sota.io

A complete static analysis service with Astrée-compatible open-source tooling, storing results in EU PostgreSQL:

FROM debian:bookworm-slim AS builder

RUN apt-get update && apt-get install -y \
    build-essential cmake git \
    libgmp-dev libmpfr-dev libppl-dev \
    python3 python3-pip \
    && apt-get clean

# Frama-C/Eva as open-source Astrée-compatible alternative
RUN apt-get install -y opam && \
    opam init --disable-sandboxing -y && \
    opam install -y frama-c && \
    apt-get clean

FROM debian:bookworm-slim

RUN apt-get update && apt-get install -y \
    libgmp10 libmpfr6 \
    opam postgresql-client \
    && apt-get clean

COPY --from=builder /root/.opam /root/.opam
ENV PATH="/root/.opam/default/bin:$PATH"

COPY run_analysis.sh /usr/local/bin/run_analysis
RUN chmod +x /usr/local/bin/run_analysis

CMD ["run_analysis"]

#!/bin/bash
# run_analysis.sh — abstract interpretation analysis + sota.io PostgreSQL

eval $(opam env)

for src in /workspace/src/*.c; do
  name=$(basename "$src" .c)
  
  # Frama-C/Eva: open-source abstract interpreter (Astrée-compatible approach)
  result=$(frama-c \
    -eva \
    -eva-domains octagon \
    -eva-precision 11 \
    -then -report \
    "$src" 2>&1)
  
  # Count potential runtime errors found
  errors=$(echo "$result" | grep -c "warning\|alarm" || echo "0")
  proven=$(echo "$result" | grep -c "proved" || echo "0")
  
  if [ "$errors" -eq 0 ]; then
    verdict="PROVEN_SAFE"
  else
    verdict="ALARMS_FOUND"
  fi
  
  # Store in EU PostgreSQL on sota.io
  psql "$DATABASE_URL" -c "
    INSERT INTO abstract_interp_results (
      component, analyser, verdict, alarm_count, proven_count, timestamp
    ) VALUES (
      '${name}', 'frama-c-eva-octagon', '${verdict}',
      ${errors}, ${proven}, NOW()
    ) ON CONFLICT (component, analyser) DO UPDATE SET
      verdict = EXCLUDED.verdict,
      alarm_count = EXCLUDED.alarm_count,
      proven_count = EXCLUDED.proven_count,
      timestamp = EXCLUDED.timestamp;"
  
  echo "=== ${name}: ${verdict} (${errors} alarms, ${proven} proven) ==="
done

Abstract interpretation results — alarm-free certificates and remaining potential errors — stored in EU-jurisdiction PostgreSQL. No Cloud Act exposure. ISO 26262, IEC 61508, and CRA technical documentation package data remains under German/EU jurisdiction throughout the development and certification lifecycle.

Astrée is commercially available from AbsInt GmbH (absint.com/astree). Academic and trial licences available. Frama-C/Eva (open source, CEA LIST 🇫🇷 + INRIA 🇫🇷) provides a compatible open-source abstract interpretation platform for development workflows. sota.io has a free tier — deploy your first abstract interpretation pipeline in minutes and generate formal safety evidence that satisfies Airbus-grade DO-178C requirements on EU infrastructure.