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.

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).

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.

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.

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.

Relationships to Other Abstractions

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

• AltaRica → Specification language → Formalization → Representation → Abstraction

Show alternative paths (2)

Neighborhood in Abstraction Space

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

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

• DEVS — 0.82
• Sequential Coupling — 0.80
• Event structure — 0.80
• Model Checking — 0.80
• Temporal Process Language — 0.79

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