Feedback Loop

A control structure in which a system observes the effect of its own actions (or of environmental change) and feeds that observation back to adjust subsequent behaviour toward a goal. Feedback control is the engineering backbone of self-adaptation: the MAPE-K loop is a feedback loop whose sensor readings (Monitor) close back onto the actions taken through effectors (Execute).

Making the feedback loop a first-class, visible architectural element — rather than logic buried in application code — is a recurring theme of the self-adaptive-systems literature and connects the field to classical control theory (stability, settling time, overshoot) as a source of design and assurance techniques.

In this vault

Backlinks

Linked Pages

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.

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

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

Control Theory

The engineering discipline of designing feedback controllers that drive a system toward a reference goal despite disturbances, and of analysing the resulting closed loop for properties such as stability, accuracy, settling time, and overshoot (the “SASO” properties). In self-adaptive software it is the rigorous underpinning of the Feedback Loop / MAPE-K stance: if an adaptive system is really a control loop, control theory supplies both the design methods and the guarantees.

The line runs from Feedback Control of Computing Systems (Hellerstein et al. 2004), which imports classical control into computing-systems performance management via system identification and controller design, through Engineering Self-Adaptive Systems through Feedback Loops (Brun et al. 2009), which argues the loop should be a first-class artefact, to Automated Design of Self-Adaptive Software with Control-Theoretical Formal Guarantees (Filieri, Hoffmann & Maggio 2014), which automates controller synthesis so software engineers get formal guarantees without doing the control-theory design by hand.

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

Automated Design of Self-Adaptive Software with Control-Theoretical Formal Guarantees

Reference: Filieri, A., Hoffmann, H. & Maggio, M. (2014). Automated Design of Self-Adaptive Software with Control-Theoretical Formal Guarantees. In Proc. 36th International Conference on Software Engineering (ICSE ’14), ACM, pp. 299–310. DOI: 10.1145/2568225.2568272. URL

Summary

This paper attacks a practical obstacle to using control theory for self-adaptation: designing a controller normally requires control-engineering expertise that most software engineers lack. The authors propose an automated method that, given a software system exposing a tunable knob and a measurable goal, builds a dynamic model of the system by lightweight experimentation and then synthesises a controller for it — turning controller design into a push-button step of the software process rather than a bespoke modelling exercise.

The technique performs on-line system identification to fit a simple (linear, adaptive) model relating the control input to the measured output, then automatically derives a controller whose parameters are chosen to deliver formal control-theoretic guarantees: stability of the closed loop, absence of steady-state error (the goal is met in the limit), bounded settling time, and robustness to modelling inaccuracy and disturbances. Because the model is re-estimated on-line, the controller adapts as the system or environment drifts. The result is a general, reusable way to give self-adaptive software the kind of provable regulation guarantees advocated by Feedback Control of Computing Systems and Engineering Self-Adaptive Systems through Feedback Loops, without demanding that each developer become a control engineer.

Key Ideas

Automated controller synthesis: given a knob and a measurable goal, generate a controller with no manual control-theory design.
On-line system identification fits a simple adaptive model of input→output behaviour and re-estimates it as the system drifts.
Delivers formal guarantees — stability, zero steady-state error (goal convergence), bounded settling time, robustness to disturbance/model error.
Makes control-theoretic adaptation reusable and accessible to software engineers, not just control specialists.
A concrete bridge from classical control theory to the MAPE-K loop’s Plan/Execute stages.

Connections

Conceptual Contribution

Claim: Control-theoretic self-adaptation can be automated — a controller with formal stability and convergence guarantees can be synthesised from a system’s own measured behaviour, removing the control-engineering expertise barrier.
Mechanism: On-line system identification fits an adaptive linear model of the control input’s effect on the goal metric; a controller is then derived automatically to guarantee stability, zero steady-state error, bounded settling time, and robustness, and is re-tuned as the model is re-estimated.
Concepts introduced/used: Control Theory, System Identification, Feedback Loop, MAPE-K, Runtime Assurance
Stance: engineering / method
Relates to: Operationalises the control-theoretic programme of Feedback Control of Computing Systems and Engineering Self-Adaptive Systems through Feedback Loops, and supplies one form of the runtime assurance called for by Software Engineering for Self-Adaptive Systems - A Second Research Roadmap.

Summary

This book is the standard text that brings classical control theory to bear on computing systems, and it is the reference source for the control-theoretic strand of self-adaptation. Its thesis is that the performance and resource management of software systems — web servers, databases, middleware, queues — can and should be engineered with the same feedback-control apparatus used in mechanical and electrical engineering: model the system, design a controller, and obtain provable guarantees about its closed-loop behaviour rather than tuning by trial and error.

The authors develop the toolkit systematically: black-box system identification to fit dynamic models (e.g. difference-equation / transfer-function models) to measured input–output data from a computing system; controller design (proportional, integral, PID and pole-placement techniques); and analysis of the resulting closed loop through the properties that name the book’s recurring acronym SASO — Stability, Accuracy, Settling time, and Overshoot. Worked examples target real systems such as Apache HTTP server tuning, Lotus Notes/email server admission control, and load and queue-length regulation. For the self-adaptive-systems community the book supplies the rigorous underpinning that papers like Engineering Self-Adaptive Systems through Feedback Loops invoke: when the MAPE-K loop is treated as a genuine control loop, this is where the design-and-guarantee machinery comes from.

Key Ideas

Applies classical (mostly linear) control theory to computing systems for performance and resource management.
System identification: fit empirical dynamic models to measured input/output data of a running system (black-box modelling).
Controller design: proportional/integral/PID and pole-placement controllers for computing targets.
SASO closed-loop properties — Stability, Accuracy, Settling time, Overshoot — as the analysis vocabulary.
Concrete case studies (Apache, email/Notes servers, queueing/admission control) demonstrating measured, guaranteed regulation.

Connections

Conceptual Contribution

Claim: The dynamic behaviour of computing systems can be managed with classical feedback control, yielding provable closed-loop guarantees (stability, accuracy, settling time, overshoot) instead of heuristic tuning.
Mechanism: Identify an empirical dynamic model of the target system, design a proportional/integral/PID or pole-placement controller against it, and analyse the closed loop with the SASO properties; validate on real server/queue case studies.
Concepts introduced/used: Control Theory, Feedback Loop, System Identification, MAPE-K
Stance: foundational textbook / methodology
Relates to: The rigorous control-theoretic basis behind the “loop as first-class artefact” stance of Engineering Self-Adaptive Systems through Feedback Loops and the automated controller synthesis of Automated Design of Self-Adaptive Software with Control-Theoretical Formal Guarantees.

Summary

This chapter makes a single, influential argument: the feedback loop should be a first-class, explicit entity in the engineering of self-adaptive software. The authors observe that although virtually every self-adaptive system is, at heart, one or more control loops, those loops are usually hidden — dispersed through the code and left implicit — which makes the system hard to understand, analyse, and assure. Their prescription is to surface the loop as an architectural element with named, documented parts, drawing directly on the long tradition of control engineering, where feedback loops are the primary object of design and analysis.

The paper anatomises the loop into its canonical activities — collect (sense), analyse, decide, and act — closely mirroring MAPE-K, and stresses the properties engineers must reason about by analogy to control theory: stability, accuracy, settling time, and overshoot, together with the handling of disturbances and the cost of sensing and actuation. It further argues for making the loop’s control properties explicit design concerns and for recognising when a system needs multiple, possibly interacting or hierarchical loops. By naming the feedback loop as the unit of design and importing control-theoretic vocabulary, the chapter became a standard reference for the “the loop is the architecture” stance in self-adaptive systems.

Key Ideas

Make the feedback loop first-class: name it, document its parts, and treat it as the primary architectural element — not logic buried in code.
Canonical loop activities — collect → analyse → decide → act — align with the MAPE-K phases.
Import control-engineering properties as design concerns: stability, accuracy, settling time, overshoot, disturbance rejection.
Reason explicitly about multiple and interacting loops (hierarchical or coordinated control).
Positions control theory as a source of both design guidance and assurance for adaptation.

Connections

Conceptual Contribution

Claim: Because a self-adaptive system is a feedback control system, the feedback loop should be an explicit, first-class engineering artefact whose control properties are designed and analysed, not an implicit by-product of the code.
Mechanism: Surface the loop as an architectural element with named collect/analyse/decide/act parts (the MAPE-K phases), reason about it with control-theoretic properties (stability, accuracy, settling time, overshoot), and structure systems as one or more coordinated loops.
Concepts introduced/used: Feedback Loop, MAPE-K, Control Theory, Self-Adaptation
Stance: engineering / position
Relates to: Deepens the feedback-loop theme of the SEAMS roadmaps (Software Engineering for Self-Adaptive Systems - A Research Roadmap); its control-theoretic programme is made rigorous in Feedback Control of Computing Systems and Automated Design of Self-Adaptive Software with Control-Theoretical Formal Guarantees.

Feedback Loop

In this vault

Related

Backlinks