Software Engineering for Self-Adaptive Systems: A Second Research Roadmap

Reference: de Lemos, R., Giese, H., Müller, H. A., Shaw, M., et al. (2013). Software Engineering for Self-Adaptive Systems: A Second Research Roadmap. In Software Engineering for Self-Adaptive Systems II, LNCS 7475, Springer, pp. 1–32. DOI: 10.1007/978-3-642-35813-5_1. URL

Summary

The second SEAMS roadmap, produced four years after the first, takes stock of the field’s progress and re-sets the agenda around what the community had learned to be the genuinely hard problems. Where the first roadmap partitioned the space, this one is organised around four thematic challenges that had emerged as central: design space (systematically characterising the choices a designer of a self-adaptive system faces), processes (development and lifecycle processes that span design time and runtime), decentralisation of control loops (moving beyond a single MAPE-K loop to multiple, interacting control loops and coordination patterns among them), and practical run-time verification and validation (V&V).

The roadmap’s sharpest emphasis is on assurance: it argues that self-adaptive systems demand a continuous supply of evidence that requirements are still met as the system and its environment change, shifting V&V from a design-time gate to a runtime, incremental activity. It highlights the need to reason explicitly about the uncertainty that motivates adaptation, to make control loops (and their interactions) explicit architectural entities, and to develop perpetual assurance techniques — including quantitative and formal methods applied at runtime — that keep pace with adaptation. It is the standard “state of the field, part II” reference for engineering and assuring self-adaptive software.

Key Ideas

Four thematic challenges: design space, processes (design-time + runtime), decentralised control loops, and practical run-time V&V.
Decentralised control: self-adaptive systems increasingly need multiple interacting MAPE-K loops with explicit coordination, not one central loop.
Perpetual / runtime assurance: continuous, incremental evidence that goals still hold, replacing one-shot design-time verification.
Uncertainty is first-class: adaptation exists to handle it, so it must be modelled and reasoned about explicitly across the lifecycle.
Positions runtime quantitative verification and formal runtime models as key enabling techniques for assurance.

Connections

Conceptual Contribution

Claim: Four years on, the hard core of engineering self-adaptive systems is decentralised control, lifecycle processes spanning design/runtime, and — above all — continuous runtime assurance under uncertainty.
Mechanism: Reorganise the agenda around design space, processes, decentralisation of control loops, and practical run-time V&V; treat uncertainty as first-class and pursue perpetual assurance via runtime quantitative/formal verification.
Concepts introduced/used: Runtime Assurance, MAPE-K, Requirements Under Uncertainty, Feedback Loop, Runtime Quantitative Verification
Stance: roadmap / community agenda
Relates to: The sequel to Software Engineering for Self-Adaptive Systems - A Research Roadmap; its assurance emphasis is realised in Self-Adaptive Software Needs Quantitative Verification at Runtime and ActivFORMS - Active Formal Models for Self-Adaptation, and its decentralised-control theme extends the single loop of The Vision of Autonomic Computing.

Tags

#self-adaptive #software-engineering #mape-k #runtime-assurance #decentralised-control #roadmap

Backlinks

Linked Pages

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.

ActivFORMS - Active Formal Models for Self-Adaptation

ActivFORMS: Active Formal Models for Self-Adaptation

Reference: Iftikhar, M. U. & Weyns, D. (2014). ActivFORMS: Active Formal Models for Self-Adaptation. In Proc. 9th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS 2014), ACM, pp. 125–134. DOI: 10.1145/2593929.2593944. URL

Summary

ActivFORMS (“Active FORmal Models for Self-adaptation”) is an approach in which a formal model of the feedback loop is not merely used to verify a design and then discarded, but is directly executed as the running adaptation logic. The feedback loop’s MAPE-K behaviour is specified as a network of timed automata; those automata are verified against the adaptation goals (using model checking, e.g. Uppaal), and then the same verified model is deployed and executed by a virtual machine that interprets the automata at runtime. Because the artefact that runs is the artefact that was verified, ActivFORMS closes the usual gap between a verified design and the code that actually executes.

The approach’s second contribution is on-the-fly change of the adaptation logic with guarantees: because the executing model is a first-class runtime object, a new (re-verified) feedback-loop model can be installed at runtime to change how the system adapts, extending assurance from the managed application to the manager itself. ActivFORMS is a flagship example of models@run.time used for assurance: the running formal model is simultaneously the system’s knowledge, its executable controller, and the object of verification. Weyns and collaborators later extended it with runtime goal management and statistical model checking, and it stands as a canonical answer to the roadmaps’ call for practical runtime assurance of self-adaptive systems.

Key Ideas

Executable verified models: specify the MAPE-K feedback loop as timed automata, verify them, then directly execute the verified model — no separate hand-coded controller.
A model-execution virtual machine interprets the automata at runtime, eliminating the design-to-code assurance gap.
On-the-fly adaptation of the adaptation logic: install a new, re-verified feedback-loop model at runtime with retained guarantees.
Extends assurance to the managing system, not just the managed application.
A leading instance of Models@run.time for assurance; later extended with runtime goal management and statistical model checking.

Connections

Conceptual Contribution

Claim: Assurance for self-adaptive systems is strongest when the verified formal model of the feedback loop is itself executed, so the running adaptation logic and the verified artefact are one and the same — and can be replaced at runtime with retained guarantees.
Mechanism: Model the MAPE-K loop as timed automata, model-check them against goals, and run the verified model on a model-execution virtual machine as a first-class Models@run.time object that can be swapped for a re-verified model on the fly.
Concepts introduced/used: Runtime Assurance, Models@run.time, MAPE-K, Formal Verification, Feedback Loop
Stance: engineering / framework
Relates to: The formal/model-based counterpart to the probabilistic Self-Adaptive Software Needs Quantitative Verification at Runtime; a concrete realisation of the perpetual-assurance agenda in Software Engineering for Self-Adaptive Systems - A Second Research Roadmap.

Tags

Self-Adaptive Software Needs Quantitative Verification at Runtime

Reference: Calinescu, R., Ghezzi, C., Kwiatkowska, M. & Mirandola, R. (2012). Self-Adaptive Software Needs Quantitative Verification at Runtime. Communications of the ACM 55(9): 69–77. DOI: 10.1145/2330667.2330686. URL

Summary

This paper argues that self-adaptive software must move a class of quantitative analysis from design time into runtime. Non-functional requirements — reliability, availability, performance, cost — are often stated probabilistically or in terms of expected costs/rewards, and the standard design-time way to establish them is quantitative (probabilistic) model checking over Markov models (DTMCs/MDPs, CTMCs) using tools such as PRISM. The authors’ thesis is that because the environment, workloads, and component behaviours a system actually meets are only known once it is running — and keep changing — the same quantitative verification must be re-run continuously, at runtime, to check whether requirements still hold and to guide adaptation when they do not.

Concretely, the approach keeps an operational stochastic model of the system as part of the Knowledge (a Models@run.time artefact), continuously updates its parameters from monitored data (e.g. observed failure rates, response times), and re-verifies the relevant probabilistic/reward properties against that model. When verification predicts a requirement violation, the results drive the Plan step — selecting a reconfiguration whose verified properties restore the guarantees. The chief engineering challenge the paper foregrounds is efficiency: full model checking is expensive, so runtime use demands incremental and parametric verification techniques so the analysis can keep pace with adaptation. The work is a cornerstone of the runtime-assurance agenda, giving self-adaptation continuous, evidence-based guarantees rather than one-off design-time certificates.

Key Ideas

Move quantitative verification from design time to runtime: continuously re-check probabilistic/reward requirements as conditions change.
Keep an operational stochastic model (DTMC/MDP/CTMC) in the system’s runtime knowledge, updated from monitored data.
Verification results drive adaptation: a predicted violation triggers selection of a reconfiguration with verified properties.
Targets non-functional requirements — reliability, performance, availability, cost — that are naturally quantitative.
Central obstacle is efficiency; needs incremental/parametric model checking to run within the MAPE-K loop’s time budget.

Connections

Conceptual Contribution

Claim: Because the conditions under which non-functional requirements must hold are known only at runtime and keep changing, quantitative (probabilistic) verification has to be performed continuously at runtime, not once at design time.
Mechanism: Maintain a parametric stochastic model of the system in the runtime knowledge base, update it from monitored data, and re-run quantitative model checking (reliability/performance/cost properties) to detect predicted violations and choose verified reconfigurations — using incremental/parametric techniques for efficiency.
Concepts introduced/used: Runtime Quantitative Verification, Runtime Assurance, Models@run.time, MAPE-K, Formal Verification
Stance: engineering / position + method
Relates to: A concrete realisation of the perpetual-assurance goal of Software Engineering for Self-Adaptive Systems - A Second Research Roadmap; the probabilistic counterpart to the model-based runtime formal methods of ActivFORMS - Active Formal Models for Self-Adaptation.

Tags

Software Engineering for Self-Adaptive Systems - A Research Roadmap

Software Engineering for Self-Adaptive Systems: A Research Roadmap

Reference: Cheng, B. H. C., de Lemos, R., Giese, H., Inverardi, P., Magee, J., et al. (2009). Software Engineering for Self-Adaptive Systems: A Research Roadmap. In Software Engineering for Self-Adaptive Systems, LNCS 5525, Springer, pp. 1–26. DOI: 10.1007/978-3-642-02161-9_1. URL

Summary

This roadmap — the outcome of a Dagstuhl seminar bringing together the self-adaptive-systems community — is the first attempt to organise self-adaptation as a software-engineering discipline rather than a collection of point techniques. It frames self-adaptation as the response to increasing scale, dynamism, and uncertainty in operating environments, where systems must adjust at runtime with reduced human intervention, and argues that the classic engineering activities (requirements, design, verification, process) all need to be rethought when much of the decision-making is deferred to runtime.

Its most-cited contribution is a set of four views that partition the research agenda: modelling dimensions (a vocabulary for classifying self-adaptive systems — e.g. what is adapted, when, why, and how), requirements (specifying adaptation goals and tolerated uncertainty, including languages that “relax” requirements), engineering (making the feedback loop a first-class design element and reusing control-loop architectures such as MAPE-K), and assurance (providing runtime evidence, verification, and validation that adaptation preserves goals). The paper repeatedly emphasises the feedback loop as the architectural centre of gravity — echoing control engineering — and lays out open challenges that framed the field for a decade.

Key Ideas

Reframes self-adaptation as a software-engineering problem: requirements, design, assurance, and process must all account for runtime decision-making under uncertainty.
Four research views: modelling dimensions, requirements, engineering, and assurance.
Modelling dimensions give a shared classification vocabulary (goals, change, mechanisms, effects) for comparing self-adaptive systems.
Makes the feedback loop / MAPE-K control loop a first-class, visible design element rather than buried logic.
Names assurance (continuous, runtime evidence that goals still hold) as a defining open challenge.

Connections

Conceptual Contribution

Claim: Self-adaptation should be treated as a first-class software-engineering discipline; its distinctive challenges — deferring decisions to runtime under uncertainty — reshape requirements, design, assurance, and process.
Mechanism: Partition the agenda into four views (modelling dimensions, requirements, engineering, assurance), elevate the feedback/MAPE-K loop to an explicit architectural element, and demand continuous runtime assurance rather than one-off design-time verification.
Concepts introduced/used: Feedback Loop, MAPE-K, Runtime Assurance, Requirements Under Uncertainty, Adaptation Dimensions
Stance: roadmap / community agenda
Relates to: The first of the two SEAMS roadmaps; its successor Software Engineering for Self-Adaptive Systems - A Second Research Roadmap deepens the assurance and control agenda. Complements the taxonomy of Self-Adaptive Software - Landscape and Research Challenges and the feedback-loop treatment of Engineering Self-Adaptive Systems through Feedback Loops.

Tags

Runtime Quantitative Verification

The application of quantitative (probabilistic) model checking — verifying reliability, performance, availability, and cost/reward properties over stochastic models such as discrete- and continuous-time Markov chains and Markov decision processes — continuously at runtime rather than only at design time. An operational stochastic model of the system is kept in the runtime knowledge as a Models@run.time artefact, its parameters are updated from monitored data, and the relevant properties are re-verified so that predicted requirement violations can trigger and guide adaptation.

Introduced as an agenda for self-adaptation by Self-Adaptive Software Needs Quantitative Verification at Runtime (Calinescu, Ghezzi, Kwiatkowska & Mirandola 2012), it is a central technique of Runtime Assurance. Its practicality hinges on efficiency — incremental and parametric verification methods that fit inside the adaptation loop’s time budget.

In this vault

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

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

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

Runtime Assurance

The provision of continuous, runtime evidence that a self-adaptive system still satisfies its requirements as the system, its environment, and its workload change — replacing (or supplementing) one-shot design-time verification with an incremental, always-on activity. Because self-adaptation defers decisions to runtime precisely to cope with uncertainty, the guarantees must be re-established at runtime too; the SEAMS roadmaps call this perpetual assurance and treat it as the field’s defining challenge.

Runtime assurance is realised through several complementary techniques in this vault: quantitative (probabilistic) verification at runtime (Self-Adaptive Software Needs Quantitative Verification at Runtime), executable verified formal models of the feedback loop (ActivFORMS - Active Formal Models for Self-Adaptation), and control-theoretic guarantees synthesised for the adaptation controller (Automated Design of Self-Adaptive Software with Control-Theoretical Formal Guarantees). All of them keep a runtime model in the MAPE-K knowledge base and re-check goals against it as conditions drift.

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

Engineering Self-Adaptive Systems through Feedback Loops

Reference: Brun, Y., Di Marzo Serugendo, G., Gacek, C., Giese, H., Kienle, H., Litoiu, M., Müller, H., Pezzè, M. & Shaw, M. (2009). Engineering Self-Adaptive Systems through Feedback Loops. In Software Engineering for Self-Adaptive Systems, LNCS 5525, Springer, pp. 48–70. DOI: 10.1007/978-3-642-02161-9_3. URL

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.

Tags

Self-Adaptive Software - Landscape and Research Challenges

Self-Adaptive Software: Landscape and Research Challenges

Reference: Salehie, M. & Tahvildari, L. (2009). Self-Adaptive Software: Landscape and Research Challenges. ACM Transactions on Autonomous and Adaptive Systems (TAAS) 4(2), Article 14. DOI: 10.1145/1516533.1516538. URL

Summary

This survey organises the self-adaptive-software field into a coherent taxonomy and a research roadmap. Its recurring analytic device is a set of “self-*” questions derived from the classic journalistic hexad — where, what, when, why, who, how — used to structure both what a system adapts and how it is built. The authors position self-adaptation against the neighbouring traditions of Autonomic Computing, multi-agent systems, control theory, and machine learning, and distil their shared structure into an adaptation feedback loop of the MAPE-K form.

On what and where, the survey classifies adaptation by the properties being maintained — the self- properties* (self-configuring, self-healing, self-optimising, self-protecting, and the enabling self-awareness/self-monitoring) — and by the artefacts and layers where change is applied. On when, it distinguishes reactive from proactive adaptation and static from dynamic decision-making. On how, it surveys the mechanisms of monitoring, detecting, deciding, and acting, together with the models and knowledge each phase needs.

The paper’s lasting contribution is as a map and vocabulary: it fixes the terminology (adaptation properties, the MAPE-style loop, the object and level of adaptation) that later work builds on, and it enumerates the open research challenges — engineering trustworthy adaptation, assurance and verification, handling uncertainty, and decentralised/large-scale control — that motivate much of the subsequent SEAMS-community literature.

Key Ideas

A taxonomy via the six “self-*” questions (where/what/when/why/who/how) spanning object, level, timing, and mechanism of adaptation.
Self- properties* organised into a hierarchy: general (self-managing), major (configuring/healing/optimising/protecting), and enabling (self-awareness/self-monitoring).
Adaptation loop cast in MAPE-K terms as the common structure across autonomic computing, control theory, and agents.
Reactive vs. proactive and static vs. dynamic decision-making as key design axes.
A research roadmap: assurance/verification of adaptation, dealing with uncertainty, trust, and scale/decentralisation.

Connections

Conceptual Contribution

Claim: The self-adaptive-software field can be organised by asking, of any adaptation, where/what/when/why/who/how — yielding a taxonomy of adaptation properties, objects, timing, and mechanisms that unifies autonomic computing, control theory, and agent-based approaches under a common feedback-loop structure.
Mechanism: A survey framework built on the six self-* questions and a hierarchy of self-* properties, mapped onto a MAPE-style adaptation loop, used to classify existing systems and to expose gaps (assurance, uncertainty, trust, scale).
Concepts introduced/used: Self-Adaptation, MAPE-K, Adaptation Dimensions, Self-* Properties, Assurance
Stance: survey / taxonomy
Relates to: The standard map for the cluster anchored by The Vision of Autonomic Computing; classifies architecture-based approaches like Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure and reference models like Self-Managed Systems - an Architectural Challenge, and shares its property vocabulary with the ensemble-oriented Self-Adaptation Self-Expression Self-Awareness ASCENS.