Controllare un sistema: plant, controller, sensore, attuatore

La teoria del controllo è la disciplina che, dato un sistema che si evolve secondo le sue leggi, progetta come fargli fare ciò che vogliamo agendo sui suoi ingressi. Questo capitolo fissa il vocabolario — plant, controllore, setpoint, errore, anello aperto e anello chiuso — su cui si regge tutta la Parte.

Perché questo capitolo

Nel 1788 James Watt monta sulla sua macchina a vapore due masse metalliche che girano appese a un perno. Quando il motore accelera, la forza centrifuga le allontana; quel movimento chiude parzialmente la valvola che fa entrare il vapore; il motore rallenta; le masse ricadono; la valvola riapre.

Il motore tiene la velocità da solo. Nessuno calcola, nessuno misura: un pezzo di metallo che si muove diventa un dispositivo che insegue un obiettivo. Ottant’anni dopo, nel 1868, in Inghilterra erano installati più di settantacinquemila di questi regolatori, e nessuno aveva ancora una teoria di come e perché funzionassero — o di perché, a volte, impazzissero.

Quella teoria è la control theory, in italiano teoria del controllo: la disciplina ingegneristica e matematica che studia come far comportare un sistema dinamico nel modo desiderato agendo sui suoi ingressi.

Non è una teoria che descrive un sistema. È una teoria che lo governa. La differenza è netta: la fisica ti dice come si evolve un pendolo lasciato a sé stesso; la control theory ti dice quale spinta devi dargli, istante per istante, perché stia dritto in equilibrio rovesciato nonostante qualcuno lo urti. Descrivere e governare sono due verbi diversi, e la control theory è la disciplina del secondo.

Per chi costruisce sistemi AI questo conta per una ragione precisa. Un agente che persegue un obiettivo regolando le proprie azioni è, strutturalmente, un problema di controllo. Il loop che un agente esegue — osserva lo stato, decide, agisce, osserva di nuovo — ha la stessa forma dell’anello di controllo in retroazione che regola un termostato o un’automobile col cruise control.

Avere il vocabolario del controllo rende dicibili, e quindi progettabili, comportamenti che altrimenti restano intuizioni vaghe da bar: “l’agente oscilla”, “non converge”, “reagisce troppo tardi”, “ha amplificato un errore di un tool fino a farne un disastro”. Ognuna di queste frasi, nel vocabolario del controllo, è un fenomeno con un nome, una causa e — spesso — una contromisura nota da settant’anni.

Questo è il capitolo che apre la Parte XI. Non insegna a progettare un controllore: insegna il vocabolario e la cornice con cui leggere tutti i capitoli successivi, dal PID al filtro di Kalman.

Contesto

La control theory si colloca a valle di due Parti di questa wiki e a monte di un’intera famiglia di capitoli operativi.

A monte, la teoria dei sistemi (Parte IX) fornisce gli oggetti: il concetto di sistema, di confine, di stato, di ingresso e uscita, di traiettoria. La cibernetica (Parte X) fa un passo in più e mette al centro il feedback — l’anello che misura l’errore e agisce per ridurlo — come schema del comportamento orientato a uno scopo.

La control theory eredita entrambe e aggiunge ciò che mancava: il rigore quantitativo. La cibernetica dice che il feedback governa i sistemi finalizzati ovunque, dal corpo umano alla società; la control theory dice quali sono le equazioni, quando il sistema è stabile, e come si sceglie il guadagno del controllore perché non oscilli.

La storia di questa disciplina ha date e nomi ben documentati. I dispositivi di retroazione precedono di gran lunga la loro teoria: già intorno al 270 a.C. Ktesibios di Alessandria, inventore greco, costruisce un regolatore a galleggiante per orologi ad acqua, capace di tenere costante il livello dell’acqua e quindi uniforme lo scorrere del tempo. Per due millenni questi meccanismi restano artigianato: funzionano, ma nessuno sa dire perché, né prevedere quando falliranno.

Il punto di nascita formale della teoria è il 1868, quando James Clerk Maxwell — il fisico scozzese (1831-1879) noto per le equazioni dell’elettromagnetismo — pubblica un articolo intitolato On Governors. È la prima analisi matematica rigorosa di un sistema in retroazione: Maxwell prende il regolatore di Watt, che a volte funzionava e a volte si metteva a oscillare violentemente, e mostra che la differenza dipende dalle radici di un polinomio. La domanda “perché questo regolatore impazzisce?” diventa, per la prima volta, una domanda matematica con una risposta.

Da lì il campo cresce per tappe. Negli anni Settanta dell’Ottocento Edward Routh e Adolf Hurwitz traducono l’intuizione di Maxwell in un criterio pratico — le condizioni di Routh-Hurwitz — che permette di giudicare la stabilità senza risolvere esplicitamente le equazioni.

Nel 1922 Nicolas Minorsky, ingegnere russo-americano, formalizza il controllo PID studiando il timone automatico delle navi. Nel 1927 Harold Black, ai Bell Labs, inventa l’amplificatore a retroazione negativa, che scambia guadagno per stabilità e linearità e abilita la telefonia a lunga distanza. Sempre ai Bell Labs, tra gli anni Trenta e Quaranta, Harry Nyquist e Hendrik Bode costruiscono gli strumenti del controllo classico nel dominio della frequenza.

Nel 1948 Norbert Wiener pubblica Cybernetics. Nel 1960 Rudolf Kalman inaugura il controllo moderno con l’approccio in spazio di stato. Torneremo su ciascuno di questi nomi più avanti, con il loro contesto.

Contro cosa si è affermata la control theory? Contro il progetto per tentativi. Prima di Maxwell, costruire un regolatore stabile era artigianato: si provava, si guardava, si correggeva, e se oscillava si modificava qualcosa a intuito.

Dopo Maxwell, è diventato possibile dire in anticipo se un progetto sarebbe stato stabile, senza costruirlo, partendo da un modello matematico. Quella è la transizione da arte a ingegneria — la stessa transizione che molte discipline del software stanno attraversando, dal “provo finché non smette di rompersi” al “ragiono sulle proprietà del sistema prima di eseguirlo”.

Anatomia del primo controllore

Vale la pena fermarsi sul regolatore di Watt, perché è il caso in cui i quattro blocchi del titolo — plant, controllore, sensore, attuatore — sono tutti visibili a occhio nudo, senza un grammo di elettronica.

Il plant è la macchina a vapore: riceve vapore, produce rotazione, e la sua velocità è la variabile controllata. Il setpoint è la velocità desiderata, fissata dalla geometria del meccanismo. Il sensore sono le due masse rotanti: la forza centrifuga che le solleva è una misura della velocità — più veloce gira il motore, più le masse si alzano. Il controllore è il sistema di leve che traduce l’altezza delle masse in posizione della valvola. L’attuatore è la valvola stessa, che regola l’afflusso di vapore — la variabile manipolata.

L’intero anello è meccanico, e l’errore non è mai calcolato esplicitamente come un numero: è incarnato nella geometria. Eppure il sistema insegue un obiettivo, reietta i disturbi (un carico improvviso sul motore lo rallenta, le masse cadono, la valvola apre) e — quando è progettato male — oscilla. È esattamente il fenomeno che Maxwell andò a spiegare. La control theory nasce così: non inventando il feedback, che esisteva già nel ferro, ma dandogli una teoria.

A valle, questo capitolo apre la Parte XI. I capitoli successivi prendono il vocabolario fissato qui e lo riempiono di metodi: il PID, il controllore concreto più diffuso al mondo; la stabilità di Lyapunov, che rende rigorosa l’idea di “non diverge”; il controllo robusto, che affronta l’incertezza di modello; il controllo ottimo e il model predictive control, che trasformano il controllo in un problema di ottimizzazione con vincoli; il filtro di Kalman, che stima lo stato nascosto da misure rumorose; e i due ponti finali, verso il reinforcement learning e verso gli agenti. Chi legge questo capitolo ha la mappa; i successivi sono il territorio.

L’intuizione

Prima del formalismo, tre modi distinti di vedere cosa fa la control theory: una scena domestica, il problema di un ingegnere, e un flusso di informazione. Sono lo stesso oggetto guardato da angoli diversi, e averli tutti e tre rende il formalismo successivo quasi inevitabile.

Primo angolo: la manopola e il bersaglio

Immagina una doccia in un vecchio appartamento. Vuoi l’acqua a una certa temperatura — chiamiamola il tuo bersaglio. Hai una manopola del miscelatore. Apri verso il caldo: l’acqua, dopo qualche secondo di ritardo, si scalda. Apri troppo: scotta, e tu correggi verso il freddo. Anche stavolta con ritardo.

Se sei impaziente e giri la manopola di scatto a ogni sensazione, finisci a oscillare tra gelo e ustione senza mai stabilizzarti. Se giri piano e aspetti, ci metti di più ma arrivi alla temperatura giusta e ci resti. Già questa scena domestica contiene il trade-off centrale della disciplina.

In questa scena c’è tutto. Il sistema da governare è l’impianto idraulico (il processo, o plant). Ciò che vuoi è una temperatura (il bersaglio, o setpoint). La manopola è la grandezza su cui puoi agire (la variabile manipolata). La temperatura effettiva dell’acqua è ciò che misuri con la pelle (la variabile controllata).

La differenza tra quella che vuoi e quella che senti è l’errore. E il fatto che girando di scatto si finisce a oscillare, mentre girando piano si converge — quella è la questione della stabilità, il cuore di tutta la disciplina.

La control theory è, in questa lettura, la teoria di come girare la manopola. Non una manopola qualunque: una manopola collegata a un processo che ha le sue inerzie, i suoi ritardi, i suoi disturbi (qualcuno apre un rubinetto altrove e la tua acqua cambia), e che tu non conosci mai alla perfezione.

Secondo angolo: il problema dell’ingegnere senza il volante

Cambiamo prospettiva. Sei un ingegnere e ti viene affidato un sistema fisico — un motore, un drone, una caldaia industriale. Non ti viene chiesto di descriverlo. Ti viene chiesto di farlo comportare bene: deve raggiungere certi valori, mantenerli, reagire ai disturbi, non rompersi.

Tu non hai il volante in mano. Non puoi pilotare il sistema momento per momento con la tua intuizione, perché reagisce mille volte più in fretta di te, oppure perché ci sono migliaia di copie del sistema e non puoi seguirle una a una. Devi progettare qualcosa che lo piloti al posto tuo: un dispositivo o un algoritmo che riceve informazioni dal sistema e decide gli ingressi.

Quel qualcosa è il controllore. Il problema fondamentale del controllo, in questa lettura, è un problema di delega: progettare una regola di decisione automatica, fissata in anticipo, che farà funzionare il sistema bene in tutte le situazioni che incontrerà — comprese quelle che tu, al momento del progetto, non hai previsto.

È un problema più difficile che pilotare a mano, perché devi avere ragione prima, una volta sola, per tutti i casi. È anche, non a caso, lo stesso tipo di difficoltà di chi progetta un agente: non guidi l’agente a mano su ogni task, scrivi una volta una logica che dovrà reggere task che non hai visto.

Questi due angoli — la manopola da girare bene e la delega da progettare bene — sono lo stesso problema visto dall’interno e dall’esterno. Il primo dà l’intuizione fisica; il secondo dice perché serve una teoria e non basta l’esperienza.

Terzo angolo: l’informazione che chiude l’anello

C’è una terza lettura, più astratta delle prime due ma utile per chi pensa in termini di software e di flussi di dati. Un controllore in anello chiuso è, prima di tutto, un dispositivo che fa circolare informazione.

Guarda dove va l’informazione nello schema. Il sistema produce un’uscita; un sensore la trasforma in un numero; quel numero viene confrontato con un obiettivo. La differenza — l’errore — è un’informazione condensata, un singolo segnale che riassume “quanto sei lontano da dove dovresti essere”.

Quell’informazione torna indietro e diventa la causa dell’azione successiva. L’anello è un circuito in cui l’effetto, ridotto a informazione, ridiventa causa. È questa circolarità — l’effetto che ritorna a essere causa — la firma del controllo in retroazione.

Letta così, una verità del controllo diventa ovvia: non puoi controllare ciò che non puoi misurare. Se il sensore non vede una grandezza, quella grandezza non entra mai nell’errore, e nessun controllore in anello chiuso potrà mai correggerla. Questo lega la control theory al concetto di osservabilità della teoria dei sistemi — quali parti dello stato sono ricostruibili dalle misure — e spiega perché, nel controllo moderno, scegliere i sensori è una decisione di progetto tanto quanto scegliere il controllore. L’informazione che non chiude l’anello è informazione persa.

La meccanica

Il problema fondamentale del controllo

Mettiamo in forma il problema. Servono quattro ingredienti, e nessuno è eliminabile.

Un processo dinamico (il plant): un sistema che si evolve nel tempo secondo le sue leggi. “Dinamico” significa che il suo stato cambia e che il passato influenza il futuro — un’automobile non cambia velocità istantaneamente, ha inerzia.
Un obiettivo: un valore da raggiungere e mantenere, o un comportamento da imporre.
Dei disturbi: influenze esterne, non controllate, che spingono il processo fuori dall’obiettivo.
Delle misure: informazioni sul sistema, in generale parziali e rumorose.

Il problema fondamentale del controllo è: dati questi quattro ingredienti, progettare un controllore — un dispositivo o un algoritmo — che generi gli ingressi del processo in modo che il suo comportamento rispetti l’obiettivo, nonostante i disturbi e nonostante l’incertezza sul modello del processo.

L’ultima clausola è quella che rende il problema interessante. Se non ci fossero disturbi e se conoscessimo il processo alla perfezione, basterebbe calcolare una volta per tutte la sequenza di ingressi giusta e applicarla a occhi chiusi. È la presenza di disturbi e di incertezza a rendere necessario qualcosa di più: misurare cosa succede davvero e correggersi.

Vale la pena soffermarsi sulla parola “dinamico”. Un processo dinamico è un processo dotato di memoria: il suo stato presente dipende dal passato, e questo significa che l’ingresso che dai oggi produrrà effetti che si distribuiscono nel tempo, non solo nell’istante.

Un’automobile ferma a cui dai gas non salta istantaneamente a velocità di crociera: accelera, con un transitorio. Una stanza fredda non si scalda di colpo. Questa inerzia è ciò che rende il controllo difficile e interessante — se i sistemi rispondessero istantaneamente, controllarli sarebbe banale. È anche la ragione per cui i quattro ingredienti vanno trattati nel tempo, e non come un’unica equazione statica. Qui nasce la distinzione centrale della disciplina.

Anello aperto e anello chiuso

Esistono due architetture di controllo, e capire la differenza è il primo passo non banale della disciplina.

Nel controllo ad anello aperto (open-loop), l’azione del controllore è indipendente dall’uscita del processo. Il controllore decide cosa fare in base al solo obiettivo, a priori, e non guarda mai cosa il sistema sta effettivamente facendo. Un esempio canonico: una caldaia comandata solo da un timer, che eroga calore per un tempo fisso indipendentemente dalla temperatura della casa. Un tostapane, una lavatrice a programma, un semaforo a tempi fissi: tutti open-loop.

Il pregio dell’anello aperto è la semplicità — nessun sensore, nessun confronto, costa poco. Il difetto è strutturale: se la realtà devia da come il controllore l’aveva immaginata — la casa è più fredda del previsto, il pane è più spesso — nessuno se ne accorge, e l’errore non viene corretto.

Nel controllo ad anello chiuso (closed-loop, o controllo in retroazione), l’uscita del processo viene misurata, confrontata con l’obiettivo, e la differenza — l’errore — viene “riportata indietro” come informazione che guida il controllore. L’anello si chiude: l’effetto torna a essere causa. La stessa caldaia, dotata di termostato, misura la temperatura della stanza, la confronta con il valore voluto, e accende o spegne in base allo scarto.

Il controllo ad anello chiuso ha due vantaggi documentati rispetto all’anello aperto: la reiezione dei disturbi e prestazioni garantite anche in presenza di incertezza di modello.

Il secondo punto è il più profondo e va sottolineato. Il feedback non corregge soltanto i disturbi che non potevi prevedere; corregge anche gli errori del tuo stesso modello del sistema. Anche se hai capito male come funziona il processo, finché riesci a misurare l’errore puoi ridurlo. Questo rende il feedback una delle idee più potenti dell’ingegneria: ti permette di costruire sistemi che funzionano meglio di quanto tu li capisca.

Una nota di vocabolario. In molti testi “open-loop” e “feedforward” sono usati come sinonimi. La Parte IX di questa wiki tratta a fondo la coppia feedback e feedforward: feedforward significa agire sulla base di una previsione o di una misura del disturbo a monte, prima che l’effetto si manifesti, senza chiudere l’anello sull’uscita.

Il feedforward è una strategia preziosa e si combina spesso con il feedback — un buon controllore usa entrambi: il feedforward anticipa i disturbi noti, il feedback ripulisce ciò che resta. Per questo capitolo introduttivo basta tenere fermo il contrasto principale: anello chiuso significa misurare l’uscita e correggersi; anello aperto no.

C’è infine una distinzione che chi viene dal software sente vicina. Il controllo può vivere a tempo continuo — il controllore agisce in ogni istante, e il sistema si descrive con equazioni differenziali — o a tempo discreto, a passi: il controllore si sveglia a intervalli regolari, legge, calcola, attua, e tra un passo e l’altro non fa nulla. Lo pseudocodice dell’Esempio 2 più avanti è controllo a tempo discreto. Quasi tutto il controllo implementato in software oggi è discreto, perché gira su un calcolatore che lavora a cicli. L’intervallo tra un passo e l’altro non è un dettaglio: un intervallo troppo lungo è una forma di ritardo, e i ritardi, come vedremo, destabilizzano.

Il vocabolario operativo

L’anello chiuso ha sei termini portanti. Su questi si regge tutta la Parte XI, quindi vanno fissati con cura. Prendiamo come esempio una caldaia con termostato.

Riferimento o setpoint (spesso indicato $SP$ ): il valore desiderato. “Voglio 20 gradi”. È il bersaglio.
Variabile controllata o process variable ( $PV$ ): la grandezza del sistema che vogliamo portare al setpoint. La temperatura effettiva della stanza. È ciò che misuriamo.
Variabile manipolata ( $MV$ , control signal): la grandezza su cui il controllore può effettivamente agire. La potenza erogata dal bruciatore. È la manopola.
Disturbo: qualsiasi influenza esterna non controllata che spinge la $PV$ fuori dal setpoint. Una finestra aperta, una giornata gelida.
Errore: la differenza tra ciò che vogliamo e ciò che otteniamo. In simboli, $e = SP - PV$ . È il segnale che alimenta il controllore in anello chiuso. Errore zero significa obiettivo raggiunto.
Plant o processo: il sistema da controllare, visto dal controllore. Riceve la variabile manipolata e i disturbi, produce la variabile controllata.

A questi sei si aggiungono i due dispositivi fisici nominati nel titolo del capitolo. L’attuatore è ciò che traduce il segnale di controllo in azione sul mondo: la valvola del gas, il motore, il relè. Il sensore è ciò che traduce una grandezza fisica in una misura utilizzabile: la termocoppia, l’encoder, l’accelerometro. Plant, controllore, sensore, attuatore sono i quattro blocchi di base di ogni schema di controllo.

Lo schema canonico dell’anello chiuso si percorre in ordine. Il setpoint arriva a un nodo di confronto che calcola l’errore $e = SP - PV$ . L’errore entra nel controllore, che produce la variabile manipolata. La variabile manipolata passa per l’attuatore e agisce sul plant, sul quale agiscono anche i disturbi.

Il plant produce la variabile controllata; il sensore la misura; e la misura — la $PV$ — torna al nodo di confronto. L’anello è chiuso. Finché c’è errore, il controllore agisce; quando l’errore è nullo, il sistema è dove deve stare.

Una distinzione che il vocabolario rende facile è quella tra controllo di regolazione e controllo di inseguimento. Nel primo il setpoint è fisso e il compito è tenere la variabile controllata costante contro i disturbi — un termostato che mantiene 20 gradi.

Nel controllo di inseguimento il setpoint cambia nel tempo e il compito è seguirlo — un braccio robotico che insegue una traiettoria, un autopilota che segue una rotta variabile. Sono lo stesso problema con accenti diversi: la regolazione mette l’accento sulla reiezione dei disturbi, l’inseguimento sulla velocità di risposta a un riferimento mobile.

Perché il feedback funziona, in numeri

Vale la pena rendere quantitativa l’affermazione “il feedback corregge anche gli errori di modello”, perché è il cuore della disciplina e detta a parole sembra magia.

Immagina un plant che, dato un ingresso $u$ , produce un’uscita $y = G \cdot u$ , dove $G$ è il “guadagno” del plant — quanto l’uscita risponde all’ingresso. È un modello volutamente semplificato, statico e lineare, ma basta a mostrare il meccanismo.

In anello aperto, per ottenere un’uscita desiderata $r$ daresti $u = r / G$ : ma se hai stimato $G$ male, l’uscita sbaglia in proporzione al tuo errore di stima. Sbagli $G$ del 20%, sbagli l’uscita del 20%. L’anello aperto eredita ogni errore del modello, uno a uno.

Chiudi l’anello con un controllore di guadagno $K$ che agisce sull’errore: $u = K \cdot (r - y)$ . Sostituendo e risolvendo, l’uscita diventa $y = \frac{KG}{1 + KG} \cdot r$ . La frazione $\frac{KG}{1+KG}$ è il guadagno d’anello chiuso.

Il punto è qui: se il prodotto $KG$ è grande, quella frazione è vicina a $1$ — e ci resta vicina anche se $G$ varia parecchio. Con $KG = 100$ il guadagno d’anello è $0{,}99$ ; se $G$ raddoppia e $KG$ diventa $200$ , il guadagno passa a $0{,}995$ . Un errore del 100% sui parametri del plant è diventato uno scarto sotto l’1% sull’uscita.

In parole povere, questo dice che un guadagno d’anello alto rende il sistema in anello chiuso insensibile ai parametri del plant. Non hai bisogno di conoscere bene $G$ : ti basta misurare $y$ e lasciare che l’errore lavori. È la stessa idea che Harold Black brevettò nel 1927 per gli amplificatori telefonici — scambiare guadagno in eccesso per insensibilità e linearità. È anche, vedremo nella sezione sui limiti, la stessa idea che, spinta troppo, fa oscillare il sistema.

Il segno conta: feedback negativo e positivo

C’è una sottigliezza nella definizione dell’errore che vale la pena rendere esplicita, perché è la differenza tra un sistema che si stabilizza e uno che esplode.

L’errore è stato definito come $e = SP - PV$ , e il controllore agisce per ridurlo. Questo significa che quando la variabile controllata sale sopra il setpoint, l’errore diventa negativo e l’azione di controllo spinge verso il basso; quando scende sotto, l’errore è positivo e l’azione spinge verso l’alto. L’anello si oppone alla deviazione. Questo è il feedback negativo, ed è il meccanismo che stabilizza: ogni scostamento genera una correzione che lo riduce.

Il feedback positivo fa l’opposto: l’anello amplifica la deviazione invece di opporsi. Uno scostamento genera un’azione che lo aumenta, che genera un’azione ancora più grande, in una spirale. Il feedback positivo non è sempre un difetto — è il meccanismo dietro la crescita esplosiva, le transizioni nette, gli effetti valanga — ma per un controllore di regolazione è il disastro: significa instabilità garantita. Il capitolo feedback negativo e positivo della Parte X tratta entrambi in dettaglio. Qui basta tenere fermo che il controllo che stabilizza è feedback negativo, e che un errore di segno — collegare il sensore al contrario, sbagliare la direzione dell’attuatore — trasforma un controllore in una bomba.

Le specifiche di progetto

Progettare un controllore non significa “annullare l’errore”. Significa soddisfare un insieme di specifiche, che in generale sono in tensione tra loro. Le cinque classiche:

Stabilità: il sistema in anello chiuso resta limitato — non oscilla in modo incontrollato e non diverge. È la specifica non negoziabile. Un sistema instabile è inutilizzabile e spesso pericoloso: la doccia che oscilla tra gelo e ustione, il regolatore di Watt che impazzisce. Tutte le altre specifiche si discutono solo a stabilità garantita.
Precisione a regime (steady-state accuracy): quando il transitorio si è esaurito, l’errore residuo deve essere nullo o sotto una soglia accettabile. La temperatura si assesta davvero su 20 gradi, non su 19,3.
Velocità di risposta: quanto in fretta il sistema raggiunge il setpoint dopo un cambio di obiettivo o dopo un disturbo. Si misura con grandezze come il tempo di salita e il tempo di assestamento.
Reiezione dei disturbi: quanto bene il sistema assorbe le perturbazioni esterne senza che la variabile controllata se ne accorga troppo.
Robustezza: stabilità e prestazioni reggono anche se il modello del processo è impreciso o cambia nel tempo. Il controllore non deve funzionare solo sul sistema “di carta” usato in fase di progetto, ma su quello reale, con le sue tolleranze e il suo invecchiamento.

La tensione tipica tra queste specifiche è quella che si tocca con mano nella doccia. Reagire più forte all’errore — in gergo, alzare il guadagno del controllore — rende la risposta più veloce e riduce l’errore a regime. Ma oltre una certa soglia produce overshoot (la $PV$ supera il setpoint prima di assestarsi), poi oscillazioni, infine instabilità.

Il progetto di un controllore è la negoziazione di questo trade-off, non la massimizzazione di una singola voce. Le patologie della corsa al guadagno — overshoot, ritardi, oscillazioni, divergenza — hanno un capitolo dedicato nella Parte X, stabilità, ritardi e oscillazioni.

Disturbi, rumore e incertezza: tre nemici diversi

“Disturbo” è stato usato finora come un termine unico, ma il progetto di un controllore distingue tre fonti di difficoltà, e tenerle separate aiuta a non confondere i rimedi.

Il disturbo di processo agisce sul plant: spinge la variabile controllata fuori dal setpoint. È la finestra aperta che raffredda la stanza, la pendenza della strada che rallenta l’auto, il picco di traffico che carica il servizio. La contromisura è il feedback in anello chiuso: l’errore lo rivela, il controllore lo compensa.

Il rumore di misura agisce invece sul sensore: la grandezza fisica vera è una, ma la misura che il controllore riceve è sporca, oscilla attorno al valore reale.

Qui c’è un’asimmetria sottile. Il feedback corregge i disturbi di processo, ma insegue il rumore di misura — se il controllore reagisce con guadagno alto a una misura rumorosa, traduce il rumore in azione, e l’azione affatica gli attuatori e disturba il plant. Combattere il rumore di misura non è alzare il guadagno: è filtrare, smorzare, e in ultima istanza stimare lo stato vero con strumenti come il filtro di Kalman.

L’incertezza di modello, infine, non è un segnale che entra da qualche parte: è la differenza strutturale tra il plant che il progettista ha immaginato e quello reale. Non si “misura” e non si “filtra”: si gestisce progettando per una famiglia di modelli, e questo è il mestiere del controllo robusto.

Tenere distinte queste tre fonti non è pedanteria. Confonderle porta a rimedi sbagliati: alzare il guadagno per battere quello che in realtà è rumore di misura (e così amplificarlo), oppure filtrare quello che in realtà è incertezza strutturale (che il filtro non tocca). La diagnosi corretta della fonte viene prima della scelta del rimedio.

Dominio del tempo e dominio della frequenza

Un sistema dinamico si può analizzare con due lenti, ed entrambe attraversano la Parte XI. Vale la pena nominarle subito, anche se il dettaglio è altrove.

Nel dominio del tempo si guarda come le grandezze evolvono al passare del tempo $t$ . Si lavora con equazioni differenziali — che descrivono come una grandezza cambia in funzione di sé stessa e degli ingressi — e, nel controllo moderno, con la rappresentazione in spazio di stato. Questa lente gestisce anche i sistemi non lineari e dà informazione esplicita su come si comporta la risposta nel tempo, al prezzo di un calcolo più pesante.

Nel dominio della frequenza si cambia domanda: invece di “come evolve nel tempo?”, si chiede “come risponde il sistema a ingressi oscillanti di frequenza diversa?”. Tramite strumenti matematici chiamati trasformate di Laplace e di Fourier — che riscrivono una funzione del tempo come una funzione della frequenza — le equazioni differenziali diventano equazioni algebriche, molto più maneggevoli.

È in questa lente che vivono le funzioni di trasferimento e strumenti grafici come i diagrammi di Bode e il criterio di Nyquist. Il vincolo: la lente in frequenza è applicabile solo ai sistemi lineari, o linearizzati attorno a un punto di lavoro. La Parte XII di questa wiki, dedicata a segnali e sistemi, sviluppa l’analisi in frequenza; qui basta sapere che esiste e che è una delle due ragioni della prossima distinzione.

Controllo classico e controllo moderno

La control theory ha una spaccatura interna, storica e metodologica insieme, che conviene avere chiara fin dall’inizio.

Il controllo classico (anni Trenta-Cinquanta) si occupa di sistemi SISO, dall’inglese Single-Input Single-Output: un solo ingresso e una sola uscita. Il suo strumento centrale è la funzione di trasferimento, che descrive il sistema a partire dal suo comportamento esterno — quale uscita produce per un dato ingresso — senza guardare dentro.

Il controllo classico lavora prevalentemente nel dominio della frequenza, con i diagrammi di Bode, il criterio di Nyquist, l’analisi di poli e zeri. I suoi controllori tipici sono il PID e le reti correttrici lead-lag. È nato in gran parte ai Bell Labs, per stabilizzare gli amplificatori telefonici, e si è poi diffuso nel controllo industriale e militare.

Il controllo moderno (dagli anni Sessanta) nasce con la rappresentazione in spazio di stato. Invece di guardare solo ingresso e uscita, descrive il sistema con un vettore di stato interno e con le equazioni che ne governano la transizione.

Questo apre la porta ai sistemi MIMO — Multiple-Input Multiple-Output, più ingressi e più uscite, in generale accoppiati tra loro — e ai metodi di controllo ottimo, adattativo, robusto e non lineare. Il prezzo da pagare è la perdita della comodità dell’analisi in frequenza. Il padre riconosciuto del controllo moderno è Rudolf Kalman, matematico ungherese-americano (1930-2016), che intorno al 1960 introduce l’approccio in spazio di stato, i concetti di controllabilità e osservabilità, il regolatore lineare quadratico e il filtro di Kalman.

Il concetto di stato del controllo moderno è esattamente quello della teoria dei sistemi: lo stato è l’informazione minima che, nota all’istante presente, basta a predire il futuro del sistema dati gli ingressi futuri. Il capitolo stato, transizione, traiettoria della Parte IX lo costruisce in dettaglio. Detto in una frase: il controllo moderno è la teoria dei sistemi resa operativa per il problema del governo.

La distinzione classico/moderno non è una successione in cui il secondo rende obsoleto il primo. Sono due cassette di attrezzi che convivono. Un PID — il controllore più diffuso al mondo, ancora oggi — è uno strumento classico, e per un problema SISO ben posto è spesso la scelta giusta proprio perché semplice e robusto. Lo spazio di stato serve quando il problema lo richiede: più ingressi e uscite accoppiati, vincoli espliciti, un costo da ottimizzare, dinamiche fortemente non lineari. Scegliere lo strumento è parte del mestiere.

Cosa c’è dentro un controllore

Finora il controllore è stato una scatola che “produce la variabile manipolata a partire dall’errore”. Vale la pena aprire la scatola quel tanto che basta a vedere che cosa la Parte XI riempirà.

Un controllore è, in astratto, una regola che mappa la storia dell’errore in un’azione. Le regole si distinguono per quanta storia e quale conoscenza del sistema usano.

Il controllore proporzionale dell’Esempio 1 guarda solo l’errore presente. Un PID guarda l’errore presente, la sua accumulazione passata e la sua tendenza futura — passato, presente e derivata. Un controllore a spazio di stato usa una stima dell’intero stato del sistema. Un controllore predittivo, come l’MPC, usa un modello del plant per simulare il futuro e scegliere l’azione che ottimizza una previsione.

Più la regola è ricca, più può fare — annullare l’errore a regime, anticipare i disturbi, rispettare vincoli — ma più dipende dalla bontà del modello e dalla qualità delle misure. È lo stesso trade-off di sempre, spostato di un livello: non più tra velocità e stabilità, ma tra potenza del controllore e fragilità rispetto a ciò che non sai. I capitoli successivi della Parte XI sono, in fondo, un catalogo ragionato di queste regole, dalla più semplice alla più sofisticata.

Esempi

Tre esempi deliberatamente eterogenei: uno numerico semplice, uno in pseudocodice, uno scenario reale di un sistema software.

Esempio 1 — Un termostato, numeri alla mano

Una stanza è a 16 gradi. Il setpoint è 20. Il controllore è il più semplice possibile: un controllore proporzionale, che eroga una potenza proporzionale all’errore. Diciamo che la potenza erogata sia $u = K \cdot e$ , con guadagno $K = 0{,}5$ (in unità arbitrarie di potenza per grado).

All’istante iniziale l’errore è $e = SP - PV = 20 - 16 = 4$ gradi. Il controllore eroga $u = 0{,}5 \cdot 4 = 2$ unità di potenza. La stanza si scalda, supponiamo, di 1 grado nel primo intervallo.

Ora $PV = 17$ , errore $e = 3$ , potenza $u = 1{,}5$ . Poi $PV = 18$ , $e = 2$ , $u = 1$ . Poi $PV = 18{,}7$ , $e = 1{,}3$ , $u = 0{,}65$ . La sequenza dei numeri racconta una storia.

Si nota una cosa importante. Man mano che la stanza si avvicina al setpoint, l’errore si riduce, e quindi la potenza erogata si riduce. La risposta rallenta proprio dove vorremmo che chiudesse.

Ora aggiungiamo il disturbo, che nella realtà c’è sempre. La stanza disperde calore verso l’esterno: chiamiamo questa dispersione una potenza persa costante, diciamo $1$ unità. Perché la temperatura resti ferma, il bruciatore deve erogare esattamente quella potenza persa. Ma il controllore proporzionale eroga $u = K \cdot e$ : per erogare $1$ unità di potenza con $K = 0{,}5$ , serve un errore $e = 2$ . In altre parole, il sistema si assesta non a $20$ gradi ma a $18$ : l’errore non si annulla mai, perché è proprio l’errore residuo a tenere acceso il bruciatore quel tanto che basta a compensare la dispersione.

Questo fenomeno ha un nome — errore a regime — e una causa precisa: un controllore puramente proporzionale produce azione solo se c’è errore, quindi non può sostenere un’azione costante a errore nullo. Annullarlo richiede un termine in più, che accumula l’errore nel tempo e continua a spingere finché l’errore non è davvero zero: è la parte integrale del PID, oggetto del capitolo PID (in preparazione). L’esempio mostra in piccolo perché il controllore più semplice non basta — e perché esiste una disciplina con cinquant’anni di metodi sopra il “moltiplica l’errore per una costante”.

Esempio 2 — L’anello chiuso in pseudocodice

L’anello di controllo, spogliato di ogni dettaglio fisico, è un ciclo che si ripete a intervalli regolari. Eccolo come pseudocodice.

setpoint = 20.0          # obiettivo: 20 gradi
K = 0.5                  # guadagno del controllore proporzionale

while True:
    pv = sensore.leggi()          # misura la variabile controllata
    errore = setpoint - pv        # nodo di confronto
    u = K * errore                # legge di controllo
    u = clamp(u, 0, u_max)        # l'attuatore ha limiti fisici
    attuatore.applica(u)          # agisci sul plant
    attendi(intervallo)           # il plant evolve, i disturbi agiscono

Quattro righe portano il peso concettuale. pv = sensore.leggi() è la misura. errore = setpoint - pv è il nodo di confronto. u = K * errore è la legge di controllo — qui banale, ma è il punto in cui un PID, un controllore robusto o un MPC sostituirebbero una logica più ricca. attuatore.applica(u) chiude la catena verso il mondo.

La riga clamp(u, 0, u_max) non è cosmetica: ricorda che l’attuatore ha limiti fisici — un bruciatore non eroga potenza negativa né infinita. La saturazione dell’attuatore è una delle prime cose che “rompe” la teoria lineare, e ci torniamo nella sezione sui limiti. La riga attendi(intervallo) ricorda invece che il controllo discreto vive a passi: tra un’azione e la misura successiva il plant evolve e i disturbi agiscono indisturbati.

Chi ha scritto agenti riconoscerà la forma del ciclo: osserva, calcola, agisci, aspetta, ripeti. Non è una somiglianza casuale, ed è il tema del ponte verso gli agenti.

Esempio 3 — Un autoscaler come controllore

Uno scenario software, senza un grammo di fisica. Un servizio web gira su un certo numero di repliche (istanze identiche dietro un load balancer). Il traffico varia durante la giornata. Vogliamo che la latenza media delle richieste resti sotto una soglia — diciamo 200 millisecondi.

Mappiamo sul vocabolario, termine per termine.

Il setpoint è la latenza obiettivo, 200 ms — o, equivalentemente, un valore obiettivo di utilizzo della CPU. La variabile controllata è la latenza (o l’utilizzo CPU) effettivamente misurata. La variabile manipolata è il numero di repliche: la manopola dell’autoscaler. Il disturbo è il traffico in ingresso, che nessuno controlla.

Il plant è il servizio con la sua infrastruttura: dato un numero di repliche e un livello di traffico, produce una certa latenza. Il sensore è il sistema di monitoring che raccoglie le metriche. Il controllore è la logica di autoscaling: se la latenza supera la soglia, aggiunge repliche; se scende troppo, ne toglie.

Tutte le specifiche di progetto si traducono, e vale la pena percorrerle una a una.

La stabilità: l’autoscaler non deve entrare in oscillazione — aggiungere repliche, vederle inutilizzate, toglierle, vedere la latenza risalire, riaggiungerle, in un ciclo che non si assesta mai. È un fenomeno reale, lo scaling oscillation o flapping, e ha una causa control-theoretic netta: troppo guadagno (l’autoscaler reagisce in modo aggressivo a piccole variazioni) combinato con troppo ritardo (una nuova replica impiega tempo a diventare operativa). Si combatte con gli stessi strumenti del controllo: ridurre il guadagno, introdurre isteresi (soglie diverse per salire e per scendere), aggiungere finestre di cooldown che impediscono azioni troppo ravvicinate.

La velocità di risposta: quanto in fretta l’autoscaler reagisce a un picco di traffico. Qui c’è un trade-off diretto con la stabilità — reagire più in fretta significa alzare il guadagno, e alzare il guadagno avvicina l’oscillazione.

La reiezione dei disturbi: assorbire una variazione di carico senza che la latenza sfori la soglia in modo visibile per gli utenti. La precisione a regime: a traffico stabile, la latenza deve assestarsi davvero vicino al setpoint, non costantemente sopra.

La robustezza, infine: l’autoscaler deve continuare a funzionare anche se il modello implicito “tante repliche danno tanta latenza” su cui è tarato cambia — perché è cambiato il codice del servizio, la sua impronta di memoria, o il profilo delle richieste. Un autoscaler tarato una volta e mai più rivisto è un controllore che, prima o poi, lavora su un plant che non è più quello per cui è stato progettato.

La morale dell’esempio è la stessa per ogni anello: un autoscaler progettato senza il vocabolario del controllo si tara per tentativi e, prima o poi, oscilla; progettato con quel vocabolario, è riconosciuto per quello che è — un controllore in anello chiuso — e si può ragionare sulla sua stabilità prima di metterlo in produzione.

Applicazioni pratiche

Dove si incontra la control theory, oltre ai sistemi fisici ovvi.

Nei sistemi fisici e industriali la control theory è ovunque: il cruise control dell’automobile (setpoint la velocità desiderata, disturbo la pendenza della strada), i termostati, gli autopiloti, la regolazione dei processi chimici, il controllo di assetto dei satelliti, il trajectory tracking in robotica. È la disciplina che ha reso governabili le macchine del Novecento, ed è invisibile esattamente perché funziona.

Nei sistemi software classici la struttura ad anello di controllo ricorre più di quanto si dica, spesso senza che chi la implementa la chiami così.

Un rate limiter è letteralmente un controllore: il setpoint è un tasso di richieste obiettivo, la variabile controllata è il tasso effettivo, la variabile manipolata è il ritardo o il rifiuto che il limiter introduce. Il congestion control di TCP — l’algoritmo che decide quanti dati un mittente può avere in volo — è un anello di controllo che regola la finestra di invio osservando perdite e ritardi. Gli autoscaler cloud, come nell’esempio sopra, sono controllori. Il backoff esponenziale dei retry è un controllore il cui guadagno cresce a ogni fallimento. Riconoscere questi sistemi come anelli di controllo significa poter importare cinquant’anni di sapere su quando oscillano e perché.

Nei sistemi LLM e agentici il pensiero control-theoretic — usare il vocabolario e i concetti del controllo per ragionare su sistemi che hanno la forma di anelli — è un attrezzo recente ma utile.

La temperatura di generazione è una manopola, una variabile manipolata interpretabile: bassa produce output preciso ma poco vario, alta produce output vario ma rumoroso. Lavori recenti la trattano esplicitamente come parametro di controllo adattativo, regolato in un anello esterno che osserva la qualità delle generazioni e aggiusta la temperatura di conseguenza (TAMPO, Temperature as a Meta-Policy, 2026).

La lunghezza e il costo di una generazione si possono mettere sotto controllo. Il setpoint è “risposta di circa 400 token” o “budget di 5000 token per task”; l’errore è lo scostamento dal budget; le variabili manipolate sono il prompt, gli stop token, il budget di reasoning concesso al modello. Un sistema che monitora il costo accumulato e regola questi ingressi è, a tutti gli effetti, un controllore in anello chiuso sul costo.

Un loop agentico ha bisogno di controllo della stabilità. Un loop mal progettato esibisce le stesse patologie di un anello di controllo mal tarato: oscilla — l’agente fa e disfa la stessa modifica, applica una correzione e poi la annulla — oppure diverge — non termina mai, continua a chiamare tool senza convergere all’obiettivo. Trattare il numero di iterazioni, la condizione di stop e l’escalation a un umano come variabili di un problema di controllo dà criteri di progetto al posto della taratura a sensazione.

Si può rendere concreto con un agente di coding che corregge un bug. Il setpoint è “tutti i test passano”. La variabile controllata è l’esito della suite di test, il sensore che la misura. L’errore è il numero di test ancora rossi. La variabile manipolata è la modifica al codice che l’agente propone a ogni iterazione. Il disturbo è tutto ciò che l’agente non controlla: una dipendenza che cambia, un test non deterministico, un requisito ambiguo.

Letto così, un agente che a ogni giro guarda un solo test e ci si fissa sopra sta usando un guadagno troppo alto e troppo locale: corregge un test e ne rompe due, poi insegue quelli, in un’oscillazione. Un agente che non ha una condizione di stop chiara diverge. Un agente robusto, nel senso del controllo, è quello che riduce l’errore complessivo in modo monotono e si ferma quando l’errore è zero o quando capisce che da solo non ci arriverà — e a quel punto fa escalation. Il vocabolario non risolve il problema da solo, ma dice esattamente dove guardare quando il loop si comporta male.

Una precisazione di onestà intellettuale: la control theory di un sistema LLM è oggi più una lente che una teoria con equazioni differenziali e teoremi di stabilità. È un’analogia operativa, e va marcata come tale. Ma è un’analogia che mostra strutture vere, e che porta con sé un vocabolario diagnostico — overshoot, ritardo, guadagno, errore a regime, robustezza — che rende dicibili problemi altrimenti vaghi.

Controllo e apprendimento

C’è un’ultima applicazione, più concettuale, che vale la pena fissare perché ricorre in tutta la Parte XI e collega questa Parte al reinforcement learning.

Controllo e apprendimento affrontano lo stesso problema di fondo — far comportare bene un sistema — ma da due punti di partenza opposti riguardo a quanto si conosce il sistema. La control theory classica funziona quando il modello del processo è noto: hai le equazioni del plant, e da quelle progetti il controllore. Il reinforcement learning serve quando il modello non è noto: l’agente non ha le equazioni, le scopre interagendo, esplorando, sbagliando e correggendosi.

Detto in una formula, da marcare come distinzione metodologica e non come confine rigido: si controlla quando il modello è noto, si impara quando non lo è.

Le due cose non sono separate da un muro. L’equazione di Bellman del reinforcement learning e il controllo ottimo sono parenti stretti — Richard Bellman, matematico americano, sviluppa la programmazione dinamica negli anni Cinquanta proprio come strumento di controllo. E il controllo adattativo — la branca del controllo che stima i parametri del modello mentre controlla — affronta esattamente lo stesso problema dell’RL: governare dinamiche incerte.

Nella pratica dei sistemi reali si fanno entrambe le cose: si parte da un modello approssimato e lo si raffina con i dati. Questo ponte è già tracciato nel capitolo da feedback e controllo a MDP, Bellman, RL della Parte X, e il capitolo controllo-vs-rl (in preparazione) lo svilupperà fino in fondo.

Dove si rompe

Le idee di questo capitolo sono potenti, e proprio per questo è facile usarle male. I limiti contano quanto i meccanismi.

Il modello mente, e il controllore eredita la bugia. Tutta la control theory classica si appoggia su un modello del plant.

Quel modello è sempre un’approssimazione: trascura non linearità, assume parametri costanti che costanti non sono, ignora dinamiche veloci che il progettista ha deciso di non includere.

Un controllore progettato su un modello pulito può comportarsi male sul sistema reale. È esattamente per questo che esiste il controllo robusto: progettare per una famiglia di modelli possibili, non per uno solo. Il feedback aiuta — come mostrato sopra, corregge anche gli errori sui parametri del plant — ma non è magia. C’è una differenza tra sbagliare i numeri di un modello e sbagliarne la struttura: se il plant reale ha una dinamica che il modello ignora del tutto, il feedback può non bastare, e a volte la dinamica trascurata è proprio quella che destabilizza l’anello.

Il feedback aggiunge ritardi, e i ritardi destabilizzano. Misurare, calcolare, attuare richiede tempo. Se il controllore reagisce a un’informazione vecchia, può “spingere” nella direzione sbagliata rispetto a dove il sistema è arrivato nel frattempo.

È il caso della doccia con il tubo lungo: il ritardo tra il girare la manopola e il sentire l’acqua è ciò che ti fa oscillare. Aspetti, non senti nulla, giri ancora; quando l’effetto arriva è il doppio di quello che volevi. Un anello con troppo ritardo e troppo guadagno è instabile, e la cosa insidiosa è che il ritardo non si vede nel modello statico: emerge solo quando il sistema gira. Non è un dettaglio implementativo, è una causa primaria di instabilità, e ha un capitolo dedicato nella Parte X.

Gli attuatori saturano, e la teoria lineare si spezza. La control theory classica ama i sistemi lineari, perché sono trattabili: la matematica della frazione $\frac{KG}{1+KG}$ vista sopra assume che $u = K \cdot e$ valga sempre. Ma ogni attuatore reale ha limiti: un motore ha una coppia massima, un bruciatore una potenza massima, un autoscaler un numero massimo di repliche.

Quando l’attuatore satura — la legge di controllo chiederebbe più di quanto la fisica può dare — il sistema smette di essere lineare. Emergono fenomeni che la teoria lineare non prevede, il più noto dei quali è l’integrator windup: il termine integrale di un PID continua ad accumulare errore mentre l’attuatore è già bloccato al massimo, e quando l’errore finalmente cambia segno il controllore impiega un tempo lunghissimo a “scaricarsi”. Sono problemi reali, con soluzioni note, ma vanno trattati a parte: vivono fuori dalla teoria pulita.

“Più guadagno è meglio” è un’intuizione sbagliata e pericolosa. È la trappola più comune, e la più seducente, perché a piccoli passi sembra sempre vera. Alzare il guadagno accelera la risposta e riduce l’errore a regime: ogni singolo incremento sembra un miglioramento.

Ma esiste una soglia oltre la quale il sistema fa overshoot, poi oscilla con ampiezza crescente, poi diverge. Il progetto del controllore è la negoziazione di un trade-off, non la massimizzazione di una voce. Chi tara un sistema “girando la manopola del guadagno finché va più veloce” lo porta sull’orlo dell’instabilità senza accorgersene — e l’instabilità, quando arriva, non arriva gradualmente: arriva di colpo, al primo disturbo abbastanza grande.

Non puoi controllare ciò che non puoi misurare — né ciò che non puoi muovere. Due limiti gemelli, e profondi. Se una grandezza non è osservabile — nessun sensore la cattura, direttamente o indirettamente — non entra nell’errore e nessun controllore in anello chiuso la corregge. E se una parte dello stato non è controllabile — nessuna combinazione di ingressi la influenza — nessun controllore potrà mai portarla dove serve. Osservabilità e controllabilità sono i due concetti che Kalman porta al centro del controllo moderno proprio perché segnano i confini di ciò che è possibile: prima di progettare un controllore conviene chiedersi se il problema è risolvibile in linea di principio.

Controllo non è la stessa cosa che cibernetica. Le due discipline condividono radici e concetti — Maxwell, il feedback, le Macy Conferences degli anni Quaranta — ma vanno tenute distinte. Affermazione di tipo storico-metodologico, non un’equivalenza e nemmeno una filiazione lineare: la cibernetica di Wiener è la visione ampia e interdisciplinare — comunicazione e controllo in animali, macchine, organizzazioni, mente — mentre la control theory è la branca ingegneristica e matematicamente rigorosa. Per giunta la control theory ha anche una tradizione ingegneristica autonoma — i Bell Labs, i regolatori industriali — precedente al termine “cibernetica”, coniato nel 1948. Trattarle come sinonimi appiattisce la storia di entrambe.

Controllo non è la stessa cosa che ottimizzazione. Sono imparentati: il controllo ottimo è un problema di ottimizzazione. Ma molta parte del controllo non ottimizza nulla in senso formale: un termostato, un PID ben tarato, regolano — inseguono un setpoint — senza minimizzare alcun funzionale di costo esplicito.

E un controllore può essere ottimo rispetto a un certo costo e comunque fragile rispetto all’incertezza. Confondere “controllare” con “ottimizzare” porta a credere che basti scrivere la funzione di costo giusta; spesso il problema vero è la robustezza, non l’ottimalità.

Un agente LLM non è un sistema dinamico nel senso classico. Il pensiero control-theoretic applicato agli agenti è una lente utile, ma va usata con onestà sui suoi limiti.

Lo stato di un agente — la sua finestra di contesto, la sua memoria — non evolve secondo un’equazione differenziale; i “disturbi” sono spesso input avversari o ambiguità semantiche, non rumore gaussiano; la “stabilità” di un loop agentico non si dimostra con un criterio di Nyquist. Le analogie — agent loop come anello di controllo, temperatura come variabile manipolata — sono illuminanti come analogie, e vanno marcate come tali.

Diventano un errore quando si pretende di trasferire all’agente i teoremi del controllo lineare come se fossero garanzie dimostrate. Una garanzia di stabilità vale per il sistema su cui è stata provata, con le sue ipotesi; un agente LLM non soddisfa quelle ipotesi. Il capitolo sul ponte verso gli agenti (in preparazione) tratterà esattamente dove l’analogia regge e dove si spezza.

Collegamenti

Wiener: comunicazione e controllo in animali e macchine — la cibernetica è la cornice ampia e interdisciplinare; la control theory ne è la branca ingegneristica rigorosa. Leggere i due capitoli in coppia chiarisce cosa condividono e cosa no.
Anatomia di un anello: errore, setpoint, guadagno, ritardo — il feedback-loop è il mattone su cui la control theory costruisce. Questo capitolo lo presuppone e lo rende ingegneria quantitativa.
Overshoot, ritardo, oscillazioni, divergenza — le patologie che la specifica di stabilità serve a evitare, trattate in dettaglio.
Feedback vs feedforward — la distinzione anello chiuso / anello aperto vista dal lato della teoria dei sistemi.
Stato, transizione, traiettoria — il concetto di stato che il controllo moderno eredita e rende operativo.
Cosa posso misurare, cosa posso governare — osservabilità e controllabilità, i due concetti che Kalman porta al centro del controllo moderno.
Da feedback e controllo a MDP, Bellman, RL — il ponte verso il reinforcement learning, presupposto quando questo capitolo distingue controllo e apprendimento.
pid-control-intuizione (in preparazione) — il primo controllore concreto: il PID, che chiude l’errore a regime lasciato aperto dal controllore proporzionale dell’Esempio 1.
stabilita-lyapunov-intuizione (in preparazione) — la stabilità resa rigorosa con l’idea di un’energia che decresce.
controllo-vs-rl (in preparazione) — controllare quando il modello è noto, imparare quando non lo è: la coppia control e learning approfondita.
ponte-control-agenti (in preparazione) — l’agent loop letto come problema di controllo parziale, con l’analisi onesta di dove l’analogia regge.

Per andare oltre

James Clerk Maxwell, On Governors (Proceedings of the Royal Society, 1868). L’articolo che fonda la disciplina: la stabilità del regolatore di Watt ridotta a una questione sulle radici di un polinomio. Breve e leggibile come documento storico.
Karl J. Åström e P. R. Kumar, Control: A perspective (Automatica, 2014). Una rassegna autorevole su storia, concetti e direzioni della teoria del controllo, scritta da due figure di primo piano del campo. Il riferimento migliore per la periodizzazione classico/moderno.
Norbert Wiener, Cybernetics: or Control and Communication in the Animal and the Machine (MIT Press, 1948). Il testo che colloca il feedback in un quadro interdisciplinare, utile per capire cosa la control theory condivide con la cibernetica e cosa no.
Frank L. Lewis, A Brief History of Feedback Control — cronologia compatta e affidabile dei milestone, da Ktesibios a Kalman, con date e contesto.
Karl J. Åström e Richard M. Murray, Feedback Systems: An Introduction for Scientists and Engineers (Princeton University Press) — testo introduttivo moderno, disponibile gratuitamente online, che sviluppa con cura tutto ciò che questo capitolo si limita a nominare.