Self Adaptive Systems

Self-Adaptive Systems Engineering

Engineering methodology for building software systems that autonomously manage themselves through explicit architectural separation and formal guarantees.

Decision Points

System Property Assessment → Adaptation Strategy Selection

Uncertainty Type → Model Selection

IF confidence > 90% AND drift < threshold
  THEN incremental model update (recursive least squares)
ELSE IF abrupt change detected OR confidence < 50%  
  THEN trigger re-identification experiments
ELSE IF formal guarantees required
  THEN use model checking on policies before deployment
ELSE
  THEN fallback to conservative policy + alert operators

Architecture Decision Tree

Does current system have scattered adaptation logic?
├─ YES → Extract to explicit managing/managed separation
│   └─ Can you draw clear boundary between domain logic and adaptation logic?
│       ├─ NO → Refactor with MAPE-K pattern first
│       └─ YES → Proceed with formal goal specification
└─ NO → Is this new system design?
    └─ YES → Start with single feedback layer
        └─ Expected to grow beyond 10 components?
            ├─ YES → Design hierarchical from start
            └─ NO → Single layer, plan evolution path

Failure Modes

1. Oscillation Death Spiral

Detection Rule: If system alternates between opposing states (scale up → scale down → scale up) with increasing frequency Symptom: Thrashing behavior, degrading performance despite "working" adaptation Root Cause: Controller gain too aggressive OR conflicting timescales in single layer Fix: Reduce proportional gain by 50%, add derivative term to dampen, OR separate into reactive/deliberative layers

2. Uncertainty Blindness

Detection Rule: If adaptation confidence remains constant despite changing conditions OR no confidence tracking exists Symptom: Mysterious failures in production, adaptation working in test but not reality Root Cause: Models assume certainty, no drift detection, point estimates treated as truth Fix: Add probabilistic models with confidence intervals → Track model prediction accuracy → Trigger re-learning when confidence drops below threshold

3. Goal Ambiguity Paralysis

Detection Rule: If team debates "is the adaptation working?" OR cannot define success criteria OR has conflicting informal goals Symptom: Endless tuning, stakeholder disagreements, no objective success metrics Root Cause: Informal goals ("fast and reliable") cannot drive automated decisions Fix: Formalize as executable specifications: P≥0.95[responseTime ≤ 200ms] AND cost ≤ $X/hour → Verify policies against formal goals before deployment

4. Single-Layer Complexity Explosion

Detection Rule: If adaptation component has >1000 lines OR >20 configuration parameters OR debugging requires system-wide tracing Symptom: Adding adaptation features breaks existing ones, emergent behaviors, impossible to predict changes Root Cause: Forcing different timescales into single control loop Fix: Decompose into hierarchical layers: Reactive handles immediate responses, Deliberative optimizes patterns, Reflective evolves strategy

5. Verification Avoidance

Detection Rule: If adaptation policies deployed based on intuition OR testing only happy path scenarios OR discovering issues only in production Symptom: "It worked in staging but failed in production", unpredictable behavior under load Root Cause: Adaptation space is exponential, manual testing insufficient Fix: Model check policies before deployment → Use statistical verification for probabilistic properties → Runtime monitoring of guarantee violations

Worked Examples

Example: E-commerce Platform Auto-scaling

Scenario: Online retailer needs adaptive resource management balancing response time (<200ms for 95% requests), availability (99.9% uptime), and cost (<$500/hour infrastructure).

Step 1: Architecture Decision

• Multiple conflicting goals → Formal specifications needed
• 15+ microservices → Hierarchical feedback required
• High traffic uncertainty → Probabilistic models essential

Step 2: Formal Goal Specification

Primary: P≥0.95[responseTime ≤ 200ms]
Secondary: availability ≥ 99.9% 
Constraint: cost ≤ $500/hour

Step 3: Hierarchical Design

• Reactive Layer (1-10s): Handle immediate failures, shed load, restart containers
• Deliberative Layer (5-60min): Learn traffic patterns, optimize resource allocation, update reactive policies
• Reflective Layer (daily): Evaluate if adaptation strategy achieving business goals, update models

Step 4: Controller Synthesis Deliberative layer models relationship: responseTime = f(activeServers, requestRate, cpuUtilization) From experimental data: responseTime ≈ 50 + (requestRate/activeServers) * 0.8 + cpuNoise Synthesize controller: targetServers = requestRate/targetThroughputPerServer + safetyMargin

Expert vs Novice Differences:

• Novice: Hand-codes "if CPU > 80% add server" rules
• Expert: Models system dynamics, synthesizes controller with stability guarantees, monitors model accuracy

Result: System maintains goals under 3x traffic spikes, reduces cost 40% during low-traffic periods, provides formal guarantees on response time distribution.

Quality Gates

Task complete when all conditions verified:

• Clear architectural boundary exists between managed system (domain logic) and managing system (adaptation logic)
• All adaptation goals specified in executable format with explicit tradeoff weights when goals conflict
• If >5 adaptation concerns, hierarchical layers designed with explicit timescale separation (reactive/deliberative/reflective)
• Uncertainty explicitly modeled with confidence tracking and drift detection thresholds defined
• Controller synthesis or formal verification performed before deployment of adaptation policies
• Runtime monitoring in place for all formal guarantees with alerting when violations detected
• Fallback policies defined for when models become unreliable (low confidence scenarios)
• Success metrics defined and measurable for each adaptation goal (not just "faster" but "P≥0.95[responseTime ≤ Xms]")
• Team can explain why current adaptation approach was chosen over alternatives (decision rationale documented)

NOT-FOR Boundaries

Do NOT use this skill for:

• Simple scaling that works with basic rules → Use standard auto-scaling policies instead
• Systems where adaptation changes are rare (monthly+) → Use manual operations procedures instead
• Purely reactive systems without learning requirements → Use event-driven-architecture instead
• When formal guarantees are not required → Use resilient-system-design for simpler fault tolerance
• Real-time systems where control loops add unacceptable latency → Use real-time-systems instead
• When uncertainty is negligible and models are stable → Use traditional control systems approaches

Delegate to other skills:

• For basic feedback loops: Use control-theory-for-software
• For formal verification techniques: Use formal-methods
• For architecture patterns: Use software-architecture-patterns
• For monitoring and observability: Use system-observability