🧠 Samizo-Lab AITL Controller (A-type)

A lightweight educational implementation of the
AITL layered control architecture,
designed to clearly distinguish:

• ⚙️ runtime control responsibility
• 🧠 design-time intelligence

Inner Loop : PID Controller  
Middle Loop: FSM (Finite State Machine, Safety & Mode Supervision)  
Adaptive Assist Layer: NN / RL (bounded, runtime optional)  
LLM: Offline / Non-Real-Time Design Assistant (A-type)

🔗 Links

Language	GitHub Pages 🌐	GitHub 💻
🇺🇸 English

📐 Official Architecture Definition & Reliability Boundary of AITL Controller (A-Type)

This page defines the design rationale, operating assumptions,
and verified reliability limits of the AITL architecture.

⚠️ Important Architectural Clarification

In practical runtime systems, the valid control configurations are:

• ✅ PID × FSM
• ✅ PID × FSM × NN / RL (bounded)

❌ LLM is never placed inside the real-time control loop

LLM is used exclusively outside real-time operation for:

• analysis
• design review
• architecture exploration
• documentation and explanation

🎯 Project Intent

This project demonstrates a clear and modular control-design methodology,
not the pursuit of:

• maximum performance
• autonomous intelligence
• black-box optimization

Instead, the emphasis is on:

• 🧩 architectural clarity
• 🛡 safety and determinism
• 📐 explicit responsibility separation
• 🧠 human-verifiable control logic

🏗 AITL (A-type) Design Philosophy

• PID handles continuous physical dynamics
• FSM governs discrete safety and mode transitions
• NN / RL may assist within bounded, supervised domains
• LLM supports design-time reasoning only

Intelligence is layered —
but responsibility is never ambiguous.

This controller is intended as a reference architecture,
suitable for:

• education
• architectural discussion
• early-stage system design
• safety-oriented control thinking

It is not intended as a drop-in production controller,
nor as a demonstration of autonomous AI control.

📊 Demo Result — AITL Full Demo (Ideal / Conceptual)

This figure is generated by:

demos/05_aitl_full_demo.py

▶ Full AITL Ideal Output

Note
This demo visualizes the conceptual integration of the AITL architecture
under ideal conditions and does not imply that all components
operate simultaneously in real time.

📄 Technical Document (PDF)

👉 aitl-controller-a-type.pdf

🧱 1. Project Structure

AITL-CONTROLLER-A-TYPE/
│
├── src/
│   ├── controllers/
│   │   ├── pid.py
│   │   ├── fsm.py
│   │   ├── hybrid.py
│   │
│   ├── models/
│   │   └── llm.py
│   │
│   └── core/
│       └── base.py
│
├── demos/
│   ├── 01_pid_step_response.py
│   ├── 02_fsm_mode_switch.py
│   ├── 03_hybrid_pid_fsm_demo.py
│   ├── 04_hybrid_fsm_llm_demo.py
│   ├── 05_aitl_full_demo.py
│   │
│   ├── 12_vi_current_control_sales_demo.py
│   │   └─ V–I current control comparison under aging & disturbance
│   ├── 13_aging_sweep_delta_t.py
│   │   └─ reliability metrics sweep (Δt, max|e| vs aging)
│   └── 15_fsm_explainability_demo.py
│       └─ FSM explainability & audit-ready transition rationale
│
├── data/
│   ├── aitl_full_demo_ideal.png
│   ├── aitl_full_demo_ideal.pdf
│   │
│   ├── 12_vi_current_control_sales_demo.png
│   │   └─ waveform comparison (Fixed PID / PID×FSM / AITL)
│   ├── 13_aging_sweep_delta_t.png
│   │   └─ quantitative reliability & safety metrics
│   └── 15_fsm_explainability_demo.png
│       └─ explainable FSM mode switching visualization
│
├── tests/
│
├── paper.pdf
└── README.md

⚙️ 2. AITL Architecture Overview

🔁 2.1 PID Layer

• ⏱️ variable sampling period dt
• 🔄 integral & derivative reset
• 🎚️ normal / high-response gain profiles

Role:
🛡️ Provides deterministic stability and baseline performance in real time.

🔀 2.2 FSM Layer

Switching logic:

normal → high   (if |error| > threshold_high)  
high   → normal (if |error| < threshold_low)

🧩 Provides explainable and auditable control-mode transitions.

Role:

• 🧯 supervises safety and mode selection
• 🚦 gates whether adaptive assistance is permitted
• ↩️ provides explicit fallback behavior

🧠 2.3 Adaptive Assist Layer (NN / RL, A-type)

• 📐 applies a bounded assist term under FSM supervision
• ⚡ improves recovery timing only within a verified operating region
• 🎓 educational and reproducible
  (not a claim of universal optimality)

⚠️ Note (Runtime Validity):
The recommended runtime configurations are
PID × FSM and PID × FSM × NN/RL (bounded).

🧾 2.4 LLM (Offline Design Assistant, A-type)

• 📴 used exclusively outside the real-time control loop
• 📊 supports log analysis, design review, and documentation
• 🛠️ may propose parameter updates, but does not execute control actions in real time

🚫 Strict prohibitions:

• ❌ no real-time I/O
• ❌ no direct gain injection during runtime
• ❌ no FSM state or transition control

🎮 3. Included Demos

Note:
Demos 12, 13, and 15 provide quantitative and explainable evidence
supporting reliability-related design conclusions.

🏃 4. Running the Main Demo

cd demos
python 05_aitl_full_demo.py

Output:

../data/aitl_full_demo_ideal.png

🎓 5. Educational Value

• 🧱 emphasizes architecture over tuning
• 🔍 interpretable and FSM-supervised adaptive behavior
• 👀 visual understanding of mode switching and intervention
• 📚 suitable for teaching materials and research prototypes with auditability

🚧 6. Future Plans (Clarified)

• B-Type AITL (reliability permission layer)
• 🧠 advanced FSM with multi-modes / hysteresis
• 🔀 nonlinear plants
• 🎯 RL-based bounded adaptive tuning (ε-term, FSM-supervised)
• 🧩 integration with AITL-H system

Note (Scope Clarification):
LLM is not planned as a self-optimizing runtime controller.
Any use of LLM is restricted to offline analysis, design review, and documentation.

🔍 Reliability Investigation — Plant Aging

Purpose (Normative):
This investigation provides design evidence to identify
the operational reliability boundary of A-Type.
It does not modify runtime control authority.

Beyond ideal conditions, the AITL controller was evaluated under
severe long-term plant degradation, modeled as
friction aging equivalent to 1000 days.

The objective of this investigation is not to claim superiority,
but to identify the operational boundary of adaptive control.

The primary focus is temporal reliability:

• ⏱️ recovery timing consistency (Δt)
• 🔎 degradation detectability
• 🚫 explicit criteria for when adaptation must be restricted

Representative Result — Aging Sweep (Δt vs Aging)

Interpretation (Design-Relevant, Not Marketing)

This result demonstrates that:

• 📉 all controllers degrade as plant aging progresses
• 📈 AITL improves recovery timing only within a limited aging range
• ⛔ beyond that range, continued adaptation does not preserve temporal reliability
• 📐 the degradation trend is explicitly measurable via Δt

Crucially, this means:

AITL is effective only within a clearly identifiable operating region.

Outside that region, adaptation must be restricted or stopped by design.

Why This Result Matters

This analysis does not argue that AITL is universally better.

Instead, it establishes that:

• 🧭 adaptive control has a finite, observable reliability boundary
• 🚨 that boundary can be detected before instability or failure
• 🧮 Δt serves as a design-time and run-time decision metric

In other words, the result answers:

“Until when is AITL safe to use?”

—not merely “Does it work?”

Design Implication

This finding directly motivates a reliability-first extension:

• A-Type: demonstrates adaptive capability
• B-Type: decides whether adaptation should be allowed

The reliability investigation provides the evidence layer that makes B-Type a necessary architectural evolution,
not a conceptual add-on.

Further Details

Detailed waveforms, quantitative metrics, and explainable supervisory logic
are documented separately.

👉 Full reliability analysis (reproducible evidence):

• Reliability Analysis — AITL under Plant Aging

One-Line Summary

AITL is not always beneficial — and that fact is measurable.

This investigation identifies the operating region
where adaptive control should be applied — and where it should not.

🟢 B-Type: Reliability-First AITL (Design Extension)

The A-Type results demonstrate that adaptive control has a finite reliability boundary.
Beyond a certain aging or degradation range, continued adaptation may degrade
temporal reliability (Δt) rather than improve performance.

B-Type is a design extension that transforms this empirical boundary into an explicit operational rule by introducing a dedicated reliability permission layer.

What B-Type Adds (Conceptual)

B-Type does not aim to maximize performance.
Instead, it determines whether adaptation is permitted based on monitored reliability conditions.

Typical monitored quantities include:

• ⏱️ Δt: recovery time / temporal reliability
• 📏 max‖e‖: safety envelope (worst-case deviation)
• 🎚️ ‖ΔKp‖ or dKp/dt: adaptation aggressiveness (stability risk)

Core Idea

A-Type proves adaptation capability.
B-Type enforces adaptation responsibility.

Adaptive tuning is enabled only when reliability metrics satisfy design-time acceptance criteria. If these conditions are violated, the system restricts adaptation and falls back to a conservative operating mode (e.g., fixed-gain PID control).

👉 B-Type Design Documentation (architecture & guard logic)
→ docs/b_type/

🛡️ True Robust Control — Operating Robustness as a Design Process

While A-Type demonstrates adaptive capability
and B-Type enforces reliability and responsibility,

True Robust Control addresses a deeper question:

How should robustness itself be operated
before theoretical guarantees collapse?

This theme extends the AITL framework by treating robustness
not as a fixed design result, but as an operational capability.

What Is Added Beyond A-Type and B-Type

True Robust Control introduces the following design concepts:

• 🔄 Uncertainty Δ as an observable state, not a static worst-case bound
• 📡 Frequency-aware interpretation of degradation
  • low-frequency: performance degradation
  • high-frequency: stability margin loss
  • input-side: actuator stress and saturation
• 🛑 Proactive intervention before robustness guarantees collapse
• 🧮 Selective redesign of robustness weight functions
  • \(W_s\): performance demand
  • \(W_t\): robustness margin
  • \(W_u\): actuator protection
• 🧱 Strict role separation
  • FSM decides when to intervene
  • LLM decides which design lever to move (offline only)
  • Controllers execute safely without reasoning

Position Within the AITL Framework

A-Type asks: Can the system adapt?
B-Type asks: Should the system adapt?
True Robust Control asks: How should robustness be operated?

These layers are complementary, not competing.

Documentation

📘 True Robust Control — Design Documentation
→ docs/true_robust_control/

This section is recommended when:

• H∞ control feels too static or overly conservative
• plant degradation evolves over time
• robustness decisions must be explainable and auditable
• design intervention must occur before instability

👤 7.　Author

📌 Item	Details
Name	Shinichi Samizo
Expertise	Semiconductor devices (logic, memory, high-voltage mixed-signal) Thin-film piezo actuators for inkjet systems PrecisionCore printhead productization, BOM management, ISO training
GitHub

📄 8. License

💬 9.　Feedback

Suggestions, improvements, and discussions are welcome via GitHub Discussions.