Utility Function

A scalar-valued function that maps a system state (or a candidate configuration) to a measure of how good it is against the stakeholders’ objectives, so that competing alternatives can be ranked and the best chosen. In self-adaptive and autonomic systems, utility functions are the standard basis for decision-making in the Plan step of a MAPE-K loop: rather than encoding fixed if-then adaptation rules, the manager evaluates the utility of each reachable configuration (trading off, say, performance against cost and reliability) and adapts toward the one of highest expected utility.

Utility-based control is what lets a system reconcile multiple, possibly conflicting non-functional goals and handle requirements that admit trade-offs. In this vault it underpins the utility-based strategy selection of Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure (its Stitch strategies are chosen by expected utility) and the goal-driven planning of the Three-Layer Reference Model.

In this vault

Backlinks

Linked Pages

Goal Management

(page does not exist)

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

Requirements Under Uncertainty

The problem of specifying requirements for systems that operate under uncertainty — where the environment, workload, and even the availability of components are not fully known at design time — and of making the requirements themselves adaptive so a self-adaptive system knows what it must always guarantee versus what it may trade off. Because Self-Adaptation exists precisely to handle uncertainty, requirements engineering for self-adaptive systems must express tolerated variation rather than assume a fixed, fully-specified world.

Two influential lines address this. RELAX (Whittle, Sawyer, Bencomo, Cheng & Bruel, 2009) is a requirements language that introduces explicit operators — as early as possible, as close as possible to, eventually, etc. — to mark which requirements may be relaxed and under what environmental uncertainty. Awareness Requirements (Silva Souza, Lapouchnian, Robinson & Mylopoulos, 2011) are meta-level requirements about other requirements — constraints on their runtime success/failure rates — that give the feedback loop explicit, monitorable adaptation triggers. Both connect to utility-based decision-making (see Utility Function): when requirements admit trade-offs, a utility function ranks the alternatives the MAPE-K Plan step chooses among. The SEAMS roadmaps flag requirements under uncertainty as a core open challenge.

In this vault

Self-Adaptation

A system’s capability to modify its own behaviour or structure at runtime in response to internal or environmental change, without external intervention. It is typically implemented as a MAPE-K loop (Monitor-Analyse-Plan-Execute over a Knowledge base), the control abstraction introduced by Autonomic Computing.

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

In this vault

The Vision of Autonomic Computing

Reference: Kephart, J. O. & Chess, D. M. (2003). The Vision of Autonomic Computing. IEEE Computer 36(1): 41–50. DOI: 10.1109/MC.2003.1160055. URL

Summary

This manifesto argues that the chief obstacle to further progress in computing is not raw capability but complexity: the installation, configuration, tuning, and maintenance of large heterogeneous systems is outstripping the ability of human administrators to manage them. Taking the human autonomic nervous system as its metaphor — it regulates heartbeat and temperature without conscious attention — the paper proposes autonomic computing: systems that manage themselves against high-level objectives supplied by administrators, who say what is wanted rather than how to achieve it.

The paper’s central architectural abstraction is the autonomic element: an autonomic manager wrapping a managed element, coupled to it through sensors and effectors, and running a closed control loop. That loop — Monitor, Analyse, Plan, Execute over a shared Knowledge base — is the MAPE-K loop that became the field’s organising pattern. Autonomic elements are composed into larger systems whose global self-management emerges from local manager behaviour and inter-element relationships (service agreements, negotiation).

Kephart and Chess frame the field’s goals through four self- properties*: self-configuration (systems configure themselves from high-level policy), self-healing (detect, diagnose, and repair faults), self-optimisation (continually tune performance and resource use), and self-protection (defend against and anticipate attacks). They lay out a research agenda spanning the individual-element level (theory of autonomic elements, lifecycle, learning) and the system level (emergent behaviour, negotiation, trust, and the engineering and assurance challenges of large adaptive systems).

Key Ideas

Complexity is the limiting factor; the answer is systems that manage themselves given high-level goals.
Autonomic element = autonomic manager + managed element, joined by sensors and effectors.
MAPE-K control loop: Monitor → Analyse → Plan → Execute over shared Knowledge.
Self-CHOP properties: self-configuration, self-healing, self-optimisation, self-protection.
Policy-based, goal-directed management: administrators specify objectives, not procedures.
System-level self-management as emergent from many interacting autonomic elements (agreements, negotiation, trust).
A broad research agenda naming learning, optimisation, negotiation, and assurance as open problems.

Connections

Conceptual Contribution

Claim: As systems outgrow human administrability, they must become self-managing — regulating their own configuration, health, performance, and defence against high-level objectives rather than step-by-step instructions.
Mechanism: Wrap each managed element in an autonomic manager that runs a Monitor–Analyse–Plan–Execute loop over a shared Knowledge base (MAPE-K), reading sensors and driving effectors; compose autonomic elements, coordinated by service agreements and negotiation, into self-managing systems judged by the self-CHOP properties.
Concepts introduced/used: Autonomic Computing, MAPE-K, Self-Adaptation, Feedback Loop, Models@run.time
Stance: vision / research agenda
Relates to: The origin point for the self-adaptive cluster — the architecture-based realisation in Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure, the reference architecture of Self-Managed Systems - an Architectural Challenge, and the taxonomy of Self-Adaptive Software - Landscape and Research Challenges all build on this framing. The biological metaphor complements the biology-inspired adaptation in Self-Adaptation Self-Expression Self-Awareness ASCENS.

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.

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.

Utility Function

In this vault

Related

Backlinks