Skip to content

AltaRica

Model system architecture, guarded failure behavior, repair, and stochastic events in a safety-analysis language whose structured models compile into fault trees, Markov models, simulations, and risk indicators.

Version
v2 · 2026-09-06 · History
Domain-specific #
1273
Origin domain
engineering
Subdomain
model-based safety assessment
Aliases
AltaRica modeling language, AltaRica Data-Flow, AltaRica 3.0

Core Idea

AltaRica is a domain-specific modeling language for model-based safety assessment. It lets an analyst describe a system’s component structure, flows, internal states, failure and repair events, guarded transitions, and stochastic timing in one compositional model. Assessment tools then transform or execute that model to obtain fault trees, minimal cut sets, Markov chains, simulations, reachability results, and reliability or availability indicators.[1]

AltaRica addresses a recurring safety-engineering gap. Classical fault trees and Markov models are analytically mature but can sit far from the architecture being assessed and become difficult to maintain as a design changes. AltaRica keeps an architecture-shaped source model and gives it formal state/event semantics suitable for automated assessment. AltaRica 3.0 combines a system-structure layer with Guarded Transition Systems (GTS).[2]

The recognition invariant is structured system model + state/flow variables + named events + guarded transitions with effects + failure/repair or stochastic occurrence laws + compositional synchronization + analysis-preserving compilation or execution.

Structural Signature

  • Component hierarchy: reusable classes/blocks and system instances.
  • Flows and assertions: interfaces and equations propagating abstract functional state.
  • State variables: persistent operational, failed, degraded, or repair condition.
  • Events: discrete occurrences that can change state.
  • Guards: predicates enabling a transition.
  • Actions: assignments/effects executed when the event occurs.
  • Occurrence laws: deterministic, probabilistic, or timed characterization.
  • Synchronization/composition: coordinated events and connections across components.
  • Initial state and invariants: admissible starting configuration and structural constraints.
  • Assessment projection: translation to a solver-specific model or direct simulation.
  • Traceability: analysis results map back to architecture elements and failure assumptions.

What It Is Not

It is not a fault tree, Markov chain, or stochastic Petri net; those can be generated analysis views. It is not ordinary SysML or Modelica: those emphasize system architecture or multiphysics behavior and lack AltaRica’s precise safety-event semantics unless extended.

It is not the AltaRica Wizard application. The language specification and semantics are the abstraction; editors, compilers, and solvers are implementations. Historical AltaRica, Data-Flow, and 3.0 are versions in one language lineage, not interchangeable syntaxes.

Scope of Application

AltaRica models failure propagation in aircraft, automotive, rail, nuclear, energy, and industrial systems. A component can expose nominal flows, enter failed states through events, recover through repair events, and interact with redundant or dependent components. The same architecture-shaped model can support qualitative cut-set analysis and quantitative stochastic assessment.

Model synchronization can connect safety views to system-engineering and multiphysics models. This does not make the models identical; it establishes governed correspondences among architecture elements and parameters.[3]

Clarity

Safety behavior is event-driven: between event occurrences, the discrete state is stable, although assertions can recompute flows. A transition’s guard says when it is enabled; its action says what changes; its occurrence law says how or when it fires. Conflating these roles makes probabilities or causality opaque.

Compilation preserves only declared semantics. A generated fault tree may abstract repair and sequencing; a Markov chain may require finite-state and stochastic assumptions. Every output must state the transformation and preserved properties.

Manages Complexity

Hierarchical components localize failure logic and support reuse. Explicit interfaces stop every subsystem from referring to every other subsystem. Source-level structure provides one place to update architecture and behavior, while compilers supply specialized analysis forms.

This shifts complexity rather than abolishing it. State-space explosion, common-cause failure, synchronized events, and abstraction fidelity remain. AltaRica makes those commitments inspectable and partially automatable.

Abstract Reasoning

  1. Define assessment objectives and abstraction granularity.
  2. Mirror the relevant system architecture in components and connections.
  3. Specify nominal flows, state variables, failures, repairs, guards, and effects.
  4. Assign occurrence laws only where data and interpretation support them.
  5. Compose and validate local models before system expansion.
  6. Generate the analysis representation appropriate to the question.
  7. Check transformation assumptions and state-space completeness.
  8. Validate scenarios, cut sets, and indicators against domain expertise and evidence.
  9. Maintain traceability from result back to source element and assumption.

Knowledge Transfer

The architecture/state/event/analysis chain transfers across safety-critical industries. Components and failure physics change; guarded-transition and compilation semantics remain.

The strict parent is Specification Language: AltaRica is a formal language specialized to safety models and analyzable failure behavior. Formal System and Abstract Machine describe neighboring structural aspects.

Examples

Motor pump. States are standby, working, and failed. A start event requires demand; a failure event requires working; repair restores availability. Assertions connect input flow, demand, state, and output.

Redundant power supply. Two component instances synchronize with shared demand and common-cause events; generated cut sets expose combinations that remove output.

Non-example. A spreadsheet containing component failure rates is safety data, not an AltaRica behavioral model.

Structural Tensions

  • Architecture fidelity versus assessment tractability.
  • Reusable components versus context-specific failure behavior.
  • One source model versus projection-specific information loss.
  • Formal semantics versus uncertain parameter evidence.
  • Compositional locality versus state-space explosion.
  • Tool automation versus analyst responsibility for abstraction validity.

Structural–Framed Character

Syntax, guarded transitions, and transformation semantics are structural. Modeling granularity, failure boundaries, probability sources, and acceptable conservatism are engineering-framed.

Structural Core vs. Domain Accent

The portable core is compositional state/event specification compiled into analyses. Safety failures, repair, RAMS indicators, fault trees, and stochastic assessment are constitutive domain accent; AltaRica is domain-specific.

Specification Language is the proposed immediate parent. Formal System supplies symbols and rules; Abstract Machine supplies state-transition interpretation; FMEA is a neighboring analysis practice.

The prospective queue contains one strict edge to domain_specific:specification_language. No live DAG mutation is authorized.

Relationships to Other Abstractions

Local relationship map for AltaRicaParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.AltaRicaDOMAINDomain-specific abstraction: Specification language — is a kind ofSpecificationlanguageDOMAIN

Current abstraction AltaRica Domain-specific

Parents (1) — more general patterns this builds on

  • AltaRica is a kind of Specification language Domain-specific

    Specification Language is the proposed immediate parent.

Hierarchy paths (3) — routes to 3 parentless roots

Neighborhood in Abstraction Space

AltaRica sits in a sparse region of the domain-specific corpus (87th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08

Not to Be Confused With

  • AltaRica Wizard or another tool implementation.
  • Fault tree, Markov chain, or Petri net generated from a model.
  • SysML, Modelica, Lustre, or a general programming language.
  • FMEA/FMECA.
  • One historical AltaRica version treated as the entire lineage.

References

[1] Michel Batteux, Tatiana Prosvirnova, and Antoine Rauzy, “The AltaRica 3.0 Project for Model-Based Safety Assessment,” IFAC Proceedings Volumes 46(22), 2013, 127–132. DOI 10.3182/20130904-3-UK-4041.00028. registry ↩

[2] Antoine Rauzy, “Guarded Transition Systems: A New States/Events Formalism for Reliability Studies,” Proceedings of the Institution of Mechanical Engineers, Part O 222(4), 2008, 495–505. DOI 10.1243/1748006XJRR177. registry ↩

[3] Antoine Rauzy and Cecilia Haskins, “Foundations for Model-Based Systems Engineering and Model-Based Safety Assessment,” Systems Engineering 22, 2019, 146–155. DOI 10.1002/sys.21469. registry ↩

[4] AltaRica Association, Documentation and AltaRica 3.0 specifications, accessed 2026-08-29. registry ↩