Signal Temporal Logic

Definition

Signal Temporal Logic (STL) is a spatiotemporal logic for specifying time-dependent
requirements on the trajectories of a dynamical system, introduced by Maler & Nickovic (cited in
akella2024risk as maler2004monitoring). An STL specification
is built recursively from atomic predicates by Boolean operators (, , and
their derived , ) and timed temporal operators (until , and the derived
eventually and always ) over a time interval . Beyond a Boolean
satisfied/violated verdict, STL admits a quantitative (robust) semantics that scores
how strongly a signal satisfies (positive) or violates (negative) — this real-valued
margin is what makes STL useful for risk-aware verification: the robustness becomes a random
variable whose tail (e.g. VaR / CVaR) measures how badly a controller can fail. STL is a formal
specification language and is regime-agnostic — it constrains the signal, not the plant, so it
applies equally to a free-flying or free-floating manipulator once its state trajectory is defined.

Key Equations

Symbols per notation.md. STL specifications here are interpreted over a state
signal ; the symbols below (, , ,
, , , ) are STL-specific and are not in notation.md.
Caution — local override: here is the STL specification formula, not the canonical
helix-latitude scalar of notation.md (guidance scalars: ); disambiguate
by context. Likewise here is a generic state signal, not a tracking error.

Syntax (atomic predicate from a real-valued function , then the grammar):

Robust (quantitative) semantics — the recursion that yields the satisfaction margin :

where and is the signed distance to that set.
Perturbation characterization (as stated in the source): iff every
signal with
also satisfies — i.e. is exactly the -norm perturbation radius that
preserves the verdict.

Source Support

  • akella2024risk — risk-aware planning/control/verification survey;
    presents STL syntax and both the Boolean and robust semantics (sidebars sb:stl_syntax,
    sb:stl_robustness), and motivates using the robustness as the random variable whose
    tail risk (VaR/CVaR) discriminates a “safe” controller from an unsafe one even at equal violation
    probability. The originating STL reference maler2004monitoring is cited there but not in our corpus.
  • responsibility_sensitive_safety — both encode safety as a
    formal, checkable specification; RSS gives explicit safe-distance rules, STL gives a temporal-logic
    grammar plus a quantitative margin.
  • chance_constraints — a probabilistic-satisfaction view; the STL
    robustness random variable lets a chance constraint be
    stated and (via tail measures) sharpened.
  • conditional_value_at_risk — the tail risk measure the source
    applies to the robustness ; distinguishes controllers
    with equal failure probability but different worst-case severity.
  • motion_planning_under_uncertainty — STL robustness can
    serve as the cost/constraint a risk-aware planner optimizes against under stochastic disturbances.

Open Questions

  • The source’s verification pipeline samples trajectories of a generic closed-loop system; what is
    the right predicate set to encode our inspection task (keep-out zones, standoff, pointing
    / versine pointing error, coverage timing) as an STL for a free-flying
    manipulator?
  • STL robustness is a -norm margin over a scalar signal; how should it be defined over an
    end-effector pose so the margin respects the rotation metric rather than a raw
    vector difference?
  • The survey notes that decomposing a large system-level specification into separately verifiable
    component specs (and the satisfiability of a given ) is open — how does this partition for a
    coupled base+arm system where component behaviors are dynamically coupled?