Models@run.time

The principle that a self-adaptive system should keep a causally-connected, runtime-accessible model of itself (and often of its environment and goals) that both reflects the running system and can be used to reason about and drive adaptation. Where classic model-driven engineering uses models at design time, models@run.time extends abstract models into the running system as first-class artefacts that the adaptation logic queries and updates.

Such a runtime model is the natural home for the Knowledge in a MAPE-K loop: the Monitor phase keeps it in sync with reality, and the Analyse/Plan phases reason over it rather than over raw code. Architecture-based approaches like Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure make the software architecture the runtime model against which constraints are evaluated and repairs planned.

Backlinks

Linked Pages

Three-Layer Reference Model

A reference architecture for self-managed systems proposed in Self-Managed Systems - an Architectural Challenge (Kramer & Magee 2007), adapting Gat’s three-layer architecture from autonomous robotics to self-adaptive software. It separates adaptation concerns by the timescale and abstraction at which they operate:

Component control — the running application; components self-tune and report status, with mechanisms to add, remove, and reconnect components at runtime.
Change management — a set of pre-computed plans that react to status reports and execute reconfigurations; escalates to the layer above when no applicable plan exists.
Goal management — produces new plans from high-level goals (typically slow, deliberative planning) in response to requests from change management or changes in goals.

The model is a widely-cited way to structure the Plan/Execute portions of a MAPE-K loop across abstraction layers, and frames the open research challenges (requirements, assurance, decentralised control) of the field.

In this vault

Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure

Rainbow: Architecture-Based Self-Adaptation with Reusable Infrastructure

Reference: Garlan, D., Cheng, S.-W., Huang, A.-C., Schmerl, B. & Steenkiste, P. (2004). Rainbow: Architecture-Based Self-Adaptation with Reusable Infrastructure. IEEE Computer 37(10): 46–54. DOI: 10.1109/MC.2004.175. URL

Summary

Rainbow is a framework for adding self-adaptation to existing systems by using an architectural model of the target system as the basis for monitoring, problem detection, and repair. Its core claim is that a software architecture — components, connectors, and properties — is the right level of abstraction for reasoning about system-wide adaptation: it is abstract enough to be tractable and to express global constraints (latency, cost, availability), yet concrete enough to map to real system elements. This is a concrete realisation of the MAPE-K loop where the architecture is the runtime model (see Models@run.time).

The framework provides a reusable infrastructure with clearly separated, customisable parts. Probes instrument the running system; gauges aggregate probe readings into updates on the architectural model; a model manager maintains the architecture; a constraint evaluator checks the model against invariants and triggers adaptation when they are violated; and an adaptation engine selects and carries out repairs through system-level effectors. Rainbow separates this generic machinery from a system-specific adaptation knowledge layer — the architectural style, constraints, and repair strategies — so the same infrastructure can be retargeted to different systems at much lower cost than bespoke, code-level adaptation.

Rainbow’s key engineering contribution is thus reuse: rather than weaving adaptation logic into application code, developers supply an architectural model, a set of constraints, and a library of repair strategies, and the shared infrastructure supplies the control loop. The approach is later extended with utility-based strategy selection and the Stitch adaptation language, and exercised on canonical exemplars such as the Znn.com news-service testbed, which together made Rainbow the reference example of architecture-based self-adaptation.

Key Ideas

Architecture as the locus of adaptation: reason about the system through its component-and-connector model, not its source.
Reusable control-loop infrastructure: probes, gauges, model manager, constraint evaluator, adaptation engine, effectors.
Separation of generic mechanism from system-specific adaptation knowledge (style, constraints, strategies) — the source of reuse and low retargeting cost.
Constraint-triggered repair: violated architectural invariants drive selection of a repair strategy.
Externalised adaptation: the adaptation logic lives outside the target system, keeping the application unchanged.
Later refinements: utility-based strategy selection and the Stitch strategy language; Znn.com as the standard testbed.

Connections

Conceptual Contribution

Claim: Self-adaptation should be engineered at the architectural level using a reusable framework: a runtime model of the system’s architecture, plus system-specific constraints and repair strategies, lets the same adaptation infrastructure be retargeted across systems instead of hand-coded each time.
Mechanism: Probes instrument the system; gauges update an architectural model; a constraint evaluator detects invariant violations; an adaptation engine selects repair strategies and enacts them via effectors — a MAPE-K loop over an architectural runtime model, with generic infrastructure cleanly separated from a customisable adaptation-knowledge layer.
Concepts introduced/used: Architecture-Based Adaptation, MAPE-K, Models@run.time, Software Architecture, Constraint Evaluation, Utility Function
Stance: engineering / framework
Relates to: The canonical architecture-based exemplar of The Vision of Autonomic Computing; complements the layered separation of concerns in Self-Managed Systems - an Architectural Challenge and sits inside the taxonomy of Self-Adaptive Software - Landscape and Research Challenges. Its “architecture as formal artefact” stance rhymes with pattern-based dependability in Architectural Patterns for Dependable Software Systems - SOL.

Self-Adaptive Systems

Systems that monitor and modify their own behaviour: self-organisation, self-expression, self-awareness.

Autonomic Computing

A software-engineering tradition, launched by IBM’s 2001 manifesto and crystallised in The Vision of Autonomic Computing (Kephart & Chess 2003), that responds to spiralling system complexity by building systems that manage themselves given high-level objectives. The biological metaphor is the autonomic nervous system: low-level regulation happens without conscious control so the administrator specifies what is wanted, not how to achieve it.

Autonomic systems are organised as MAPE-K loops — autonomic managers regulating managed elements — and are judged by the self- properties*: self-configuration, self-healing, self-optimisation, and self-protection (collectively “self-CHOP”). The tradition is the engineering counterpart to the biology-inspired Self-Adaptive Systems line already in this vault: where the latter asks why systems adapt, autonomic computing asks how you build and assure the adaptation.

In this vault

MAPE-K

The reference control loop of Autonomic Computing and self-adaptive software: an autonomic manager runs a closed feedback loop of Monitor → Analyse → Plan → Execute over a shared Knowledge base, acting on a managed element through sensors (probes/gauges) and effectors.

Monitor — collect and aggregate sensor data from the managed element and its environment.
Analyse — detect when adaptation is needed (symptoms, constraint/SLA violations, drift from goals).
Plan — select a course of action (a strategy/tactic, reconfiguration, or repair).
Execute — enact the plan through effectors on the managed element.
Knowledge — models, policies, goals, and history shared across the four phases (see Models@run.time).

Introduced in The Vision of Autonomic Computing (Kephart & Chess 2003) as the organising abstraction for the self-* properties (self-configuration, self-healing, self-optimisation, self-protection). It is the connective tissue linking architecture-based adaptation (Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure), reference models (Three-Layer Reference Model), and the broader survey landscape (Self-Adaptive Software - Landscape and Research Challenges).

Models@run.time

Related

Backlinks