Robustezza a rumore, incertezza e disturbi

Ogni controllore è progettato su un modello del sistema, e nessun modello è mai esatto. Il controllo robusto progetta controllori che funzionano bene non per un solo modello, ma per un intero insieme di modelli plausibili — e questo capitolo mostra perché quella scelta costa prestazione e perché conviene comprarla lo stesso.

Perché questo capitolo

Nel 1978 una nota di due pagine, pubblicata su una rivista di ingegneria del controllo, ha un abstract che è quasi diventato una battuta interna del campo. La domanda del titolo è: i regolatori LQG — la classe di controllori ottimi più celebrata degli anni Sessanta e Settanta — hanno margini di robustezza garantiti? L’abstract, nella sostanza, risponde che di margini garantiti non ce ne sono. Tre parole, per smontare una rassicurazione su cui un’intera comunità si era adagiata.

Quella nota racconta in miniatura tutto il problema di questo capitolo. Un controllore è sempre progettato su un modello del sistema da controllare. Il modello è una descrizione matematica: equazioni, parametri, numeri.

Ma il modello non è il sistema. È una mappa, e ogni mappa è in qualche misura sbagliata. I parametri fisici hanno tolleranze. Ci sono dinamiche che hai trascurato perché “troppo piccole per contare”. Ci sono disturbi che agiscono dal di fuori e che non hai messo nel modello. Un controllore tarato per essere perfetto sul modello può essere fragile sul sistema vero: può funzionare benissimo in laboratorio e rompersi sul campo, dove il sistema vero non somiglia abbastanza alla mappa.

Il controllo robusto è la disciplina che prende sul serio questa discrepanza. Non progetta per un modello: progetta per un insieme di modelli — un intorno di incertezza — e chiede al controllore di funzionare bene per ognuno di essi. La parola chiave è “bene per ognuno”, non “ottimo per uno”. Questo costa: un controllore robusto rinuncia a parte della prestazione di picco che un controllore aggressivo otterrebbe sul modello nominale, in cambio di una cosa diversa — la garanzia di non rompersi mai, qualunque sia il sistema vero dentro l’intorno dichiarato.

Per chi costruisce sistemi, questo conta su due piani. Il primo è il controllo nel senso stretto: dove il modello è incerto e il fallimento è costoso — un controllore di volo, un robot vicino a una persona, un convertitore di potenza, un anello di feedback software che governa risorse care — “ho tarato e sembra andare” non basta, e serve un metodo che dichiari quanta incertezza il sistema tollera.

Il secondo piano è più ampio. L’idea di progettare per il caso peggiore dentro un insieme — invece che per il caso nominale — è uno schema di ragionamento che ricompare, con un legame che è parentela concettuale e non identità, nel cuore del machine learning: distribution shift, robustezza avversaria, il trade-off fra aderenza ai dati e tenuta fuori da essi. Il controllo robusto dà il vocabolario per pensare quel trade-off con precisione, ed è il motivo per cui un capitolo di teoria del controllo trova posto in una wiki sull’AI.

Contesto

Questo capitolo si appoggia ai tre che lo precedono nella Parte e a uno della Parte precedente.

Presuppone il vocabolario di Controllare un sistema: plant, controller, sensore, attuatore: il plant è il sistema da controllare, il controllore è ciò che decide l’ingresso, il modello è la descrizione matematica del plant su cui il controllore viene progettato, l’anello chiuso è il sistema completo controllore-più-plant con il feedback richiuso.

Presuppone anche il PID come controllore pragmatico tarato per prove ed errori, e il progetto via Lyapunov come controllore con garanzia formale di stabilità — garanzia che però, come dichiarava la fine di quel capitolo, vale quanto il modello su cui è costruita. Il controllo robusto è esattamente la risposta a quel “vale quanto il modello”: prende il certificato che il progetto via Lyapunov dà per un singolo modello e chiede che valga per tutti i modelli di un intorno.

E presuppone, dalla Parte sulla cibernetica, Overshoot, delay, oscillazioni, divergenza: i modi tipici in cui un anello di feedback fallisce — risposta che oltrepassa il bersaglio, ritardo che spinge l’anello in oscillazione, divergenza. I margini di stabilità, che vedremo fra poco, misurano proprio quanto un anello è lontano da quei fallimenti.

La cosa nuova è il contesto storico, e vale la pena raccontarlo perché spiega da dove nasce la disciplina.

Negli anni Sessanta il controllo vive una stagione di entusiasmo. Nasce il controllo moderno: il sistema si descrive in spazio di stato — una lista di numeri che riassume la condizione del sistema istante per istante — e su questa descrizione si costruiscono metodi di progetto ottimi.

È un cambio di paradigma rispetto al controllo classico degli anni precedenti, che ragionava nel dominio della frequenza con i diagrammi di Nyquist e di Bode. Il controllo moderno promette qualcosa di più ambizioso: non un controllore tarato a sensazione, ma un controllore calcolato come soluzione ottima di un problema di minimizzazione. È una promessa seducente, e per un decennio sembrò mantenuta.

Il più celebrato di questi metodi è l’LQG, Linear Quadratic Gaussian: un controllore ottimo per sistemi lineari disturbati da rumore gaussiano. L’LQG è elegante: minimizza un costo quadratico — una misura di errore al quadrato più sforzo di controllo al quadrato — e la sua soluzione si scrive in forma chiusa.

L’LQG si ottiene accoppiando due pezzi, ciascuno ottimo per conto suo: un regolatore LQR (Linear Quadratic Regulator, la retroazione ottima a partire dallo stato) e un filtro di Kalman (la stima ottima dello stato a partire dalle misure rumorose, il tema di kalman-filter-intuizione (in preparazione)). Il fatto che accoppiare due pezzi ottimi dia un sistema ancora ottimo ha un nome — separation principle — e per un decennio sembrò una garanzia di buona salute dell’intero impianto.

Nel 1977 Michael Safonov e Michael Athans (teorici del controllo statunitensi) rinforzano quella fiducia: dimostrano che il regolatore LQR a sola retroazione di stato gode di margini di robustezza garantiti — almeno 6 dB di margine di guadagno e 60 gradi di margine di fase, di cui diremo il significato fra poco. Sembrava una proprietà strutturale rassicurante: l’ottimalità portava in dote anche la robustezza, gratis.

Un anno dopo, John C. Doyle (teorico del controllo statunitense, allora giovane ricercatore) pubblica su IEEE Transactions on Automatic Control (vol. 23, 1978, pp. 756-757) la nota “Guaranteed Margins for LQG Regulators”. Doyle costruisce un controesempio: un sistema in cui il passaggio dall’LQR — sola retroazione di stato — all’LQG completo, con il filtro di Kalman che stima lo stato dalle misure, distrugge i margini. Non li riduce: li fa diventare arbitrariamente piccoli.

Il punto sottile è proprio questo. I margini garantiti di Safonov e Athans valevano per la retroazione di stato, cioè quando lo stato è misurato direttamente. Ma aggiungere lo stimatore — il filtro di Kalman, per ricostruire lo stato dalle misure rumorose, cosa che ogni sistema reale deve fare perché lo stato completo non è quasi mai misurabile — può azzerare quei margini. Il separation principle garantiva l’ottimalità dell’accoppiamento, non la sua robustezza: due garanzie diverse, che era facile confondere.

La conseguenza è netta: un sistema LQG può essere nominalmente ottimo e instabilizzarsi per una perturbazione minuscola del modello. La conclusione — i regolatori LQG non hanno margini garantiti — è uno spartiacque. Mette in chiaro che ottimalità rispetto a un modello e robustezza rispetto all’incertezza del modello sono due cose diverse, e che la prima, comprata senza guardare la seconda, è una garanzia solo sulla carta.

La risposta della comunità, fra la fine degli anni Settanta e gli anni Ottanta, è la nascita del controllo robusto come disciplina con strumenti propri. L’altro nome cardine è George Zames (teorico del controllo canadese-statunitense). Zames aveva formulato negli anni Sessanta il small-gain theorem, uno strumento che vedremo.

Nel 1981, nel paper “Feedback and Optimal Sensitivity” (IEEE Transactions on Automatic Control, vol. 26), Zames riformula il problema del controllo come minimizzazione di una norma — la norma H-infinito — della funzione di sensitività. Da lì nasce il controllo H-infinito, il metodo centrale del controllo robusto lineare. Negli anni successivi Doyle stesso, insieme a Keith Glover, Bruce Francis e altri, ne fornisce le soluzioni in spazio di stato e introduce il valore singolare strutturato, lo strumento alla base della mu-synthesis.

Il filo storico, allora, è questo: il controllo robusto non nasce da un’idea isolata ma da una correzione di rotta. Il controllo moderno aveva inseguito l’ottimalità rispetto a un modello; la nota di Doyle ha mostrato che quell’ottimalità, da sola, non bastava; e la disciplina che ne è seguita ha rimesso al centro una domanda che il controllo classico in frequenza, con i suoi margini, non aveva mai del tutto perso di vista — quanta incertezza il sistema tollera.

L’intuizione

Tre angoli, prima di qualunque formalismo. Il primo dice cos’è l’incertezza del modello e come il controllo robusto la affronta. Il secondo dà la lettura che apre il ponte verso il machine learning: il caso peggiore come avversario. Il terzo, più vicino all’economia, chiarisce perché la robustezza ha un prezzo che non si può azzerare.

Primo angolo: la mappa non è il territorio

Un controllore è progettato su una mappa del sistema: il modello. Il sistema vero è il territorio. La mappa è sempre, in qualche misura, sbagliata. Le ragioni sono tre, e conviene tenerle distinte perché il controllo robusto le tratta in modo diverso.

La prima: i parametri sono incerti. Hai misurato una massa a 2,5 kg, ma il pezzo che monti in produzione pesa fra 2,3 e 2,7. Hai stimato un attrito a 20 gradi, ma il sistema lavora anche a 50. I numeri dentro le equazioni ballano.

La seconda: ci sono dinamiche non modellate. Il modello cattura i comportamenti che ti interessano — il moto principale, la risposta lenta — e trascura il resto: un modo di vibrazione veloce della struttura, una flessibilità di un giunto, un ritardo che hai approssimato a zero. Non è che hai sbagliato i numeri: hai proprio omesso pezzi di fisica, perché sembravano “troppo veloci o troppo piccoli per contare”. A volte contano.

La terza: i disturbi. Forze esterne che agiscono sul sistema e che il controllore non comanda — una raffica di vento sul velivolo, un picco di carico sul convertitore, una richiesta improvvisa di traffico sull’autoscaler. Il disturbo non è un errore del modello: è un ingresso che non controlli.

Il controllo nominale traccia il percorso sulla mappa e cammina a occhi chiusi, fidandosi che la mappa sia esatta. È la scelta di un controllore aggressivo: ottimizzato per il modello nominale, splendido se il territorio gli somiglia, fragile se non gli somiglia.

Il controllo robusto fa qualcosa di diverso. Disegna attorno alla mappa una fascia di errore: “il territorio vero sta da qualche parte dentro questa fascia”. La fascia è l’intorno di incertezza — l’insieme di tutti i modelli plausibili.

Poi il controllo robusto progetta un percorso che resta valido per ogni territorio dentro la fascia. Il percorso robusto non è il più corto per nessuno dei territori possibili — paga questo prezzo — ma è percorribile per tutti. È la differenza che riassume il capitolo: il controllo nominale ottimizza per la mappa, il controllo robusto ottimizza per il caso peggiore dentro la fascia.

Secondo angolo: il caso peggiore come avversario

C’è un secondo modo di vedere la stessa scena, ed è quello che apre il ponte verso il resto della wiki. Il controllo robusto si può leggere come un gioco a due giocatori.

Tu fai la prima mossa: scegli il controllore. Poi muove un avversario — chiamiamolo “la natura”. L’avversario muove dopo di te e sapendo cosa hai scelto: guarda il tuo controllore e poi sceglie, dentro l’intorno di incertezza, il modello peggiore e il disturbo peggiore — quelli che mettono più in difficoltà proprio il controllore che hai messo in campo. Tu vuoi che il sistema resti stabile e performante; l’avversario vuole romperlo.

Il controllo robusto è la tua strategia ottima in questo gioco. È il controllore che minimizza il danno massimo che l’avversario, giocando al suo meglio, può infliggerti. In una formula: tu minimizzi su tutti i controllori, l’avversario massimizza su tutta l’incertezza, e tu cerchi il controllore che vince questo min-max. È esattamente lo schema dei giochi a somma zero e del minimax: tu minimizzi, l’avversario massimizza, e la soluzione robusta è il punto di sella del gioco.

Questa lettura non è un ornamento. È il punto di contatto con il machine learning. L’adversarial training — addestrare un modello contro un avversario che sceglie la perturbazione peggiore dell’input — e la distributionally robust optimization — ottimizzare contro un avversario che sceglie la distribuzione peggiore dei dati — sono anch’essi giochi min-max contro un avversario che sceglie il caso peggiore.

La parentela è strutturale: lo stesso schema di ottimizzazione. Ma va detto subito, e con precisione, di che classe di legame si tratta — perché ci torneremo a lungo, e perché è esattamente il tipo di affermazione che scivola se non la si marca. È una parentela concettuale, non una identità. Lo schema min-max è lo stesso, ma gli oggetti su cui si gioca sono diversi: nel controllo robusto l’avversario sceglie un modello dinamico; nel machine learning sceglie una perturbazione di un input o una distribuzione di dati. Lo schema è condiviso; gli oggetti no. Tenere ferma questa distinzione è una delle discipline portanti del capitolo.

Terzo angolo: l’assicurazione e il suo premio

Un terzo modo di vedere la stessa scena, più vicino all’economia che alla geometria, chiarisce perché la robustezza costa.

Comprare robustezza è come comprare un’assicurazione. Un’assicurazione ha un premio: paghi qualcosa, ogni mese, anche nei mesi in cui non succede niente. In cambio ottieni che, se succede il danno, non sei rovinato. Chi non si assicura tiene in tasca il premio — sta meglio finché tutto va bene — ma è esposto al danno pieno se la sfortuna arriva.

Il controllo robusto è la scelta di assicurarsi. Il premio è la prestazione di picco a cui rinunci: il controllore robusto, sul modello nominale, è più lento e meno preciso di uno aggressivo — paga il premio anche nei “mesi” in cui il sistema vero coincide col nominale e l’assicurazione non serve. Il danno da cui ti protegge è la rottura: l’instabilità quando il sistema vero si discosta dalla mappa. Il controllore aggressivo è chi non si assicura: splendido finché il territorio somiglia alla mappa, rovinato quando non le somiglia.

Questa lettura rende esplicito un punto che le altre due lasciano implicito. La robustezza non è gratis e non può esserlo: un’assicurazione senza premio non esiste. Chiedere “voglio un controllore robusto e anche il più performante possibile sul nominale” è come chiedere un’assicurazione che non costa niente. E come per un’assicurazione vera, la domanda giusta non è “premio sì o no?”, è “quanto premio, per coprire quale danno?” — che è esattamente la scelta del punto sulla frontiera di cui parleremo più avanti.

I margini di stabilità: la prima forma di robustezza

Prima che il controllo robusto diventasse una disciplina formale con la sua matematica, l’ingegneria del controllo classico aveva già un modo grezzo ma efficace di quantificare la robustezza: i margini di stabilità. Sono il punto di partenza naturale, perché sono robustezza misurata con due soli numeri, e perché collegano direttamente questo capitolo a Overshoot, delay, oscillazioni, divergenza.

L’idea. Un anello di feedback ha un confine tra stabile e instabile. Il controllo classico legge quel confine dalla risposta in frequenza dell’anello — quanto l’anello amplifica e quanto sfasa un segnale, frequenza per frequenza. La distanza dal confine si riassume in due margini.

Il margine di guadagno misura di quanto si può moltiplicare il guadagno dell’anello — quanto amplifica — prima che il sistema diventi instabile. Si esprime in decibel. Un margine di guadagno di 6 dB corrisponde a un fattore 2 in ampiezza: significa che il guadagno reale dell’anello può arrivare al doppio del nominale, e l’anello regge ancora.

Il margine di guadagno è già robustezza, perché parla direttamente di incertezza. Se la tua incertezza sul guadagno del plant è “può variare del più o meno trenta per cento”, 6 dB di margine la coprono con abbondanza. Se invece il guadagno reale, in certe condizioni di carico, può triplicare, 6 dB non bastano. Il margine è il budget; l’incertezza è la spesa.

Il margine di fase misura quanto ritardo di fase extra l’anello tollera prima di entrare in oscillazione. Si esprime in gradi. Un margine di fase di 60 gradi è considerato confortevole; sotto i 30 gradi l’anello è fragile e tende a oscillare.

Il legame del margine di fase con il capitolo sui ritardi è diretto. Un ritardo non modellato — un sensore lento, un attuatore con latenza, un tempo di calcolo trascurato — aggiunge sfasamento e mangia margine di fase. Quando il margine si azzera, l’anello entra in oscillazione: è uno dei modi di rottura descritti in Overshoot, delay, oscillazioni, divergenza. Un controllore con margine di fase ampio tollera ritardi che non avevi messo nel modello; uno con margine stretto si rompe al primo ritardo imprevisto.

Perché i margini sono robustezza? Perché misurano quanta incertezza su guadagno e ritardo l’anello sopporta prima di rompersi. Un anello con margini ampi è robusto a errori di modello su quei due assi; un anello con margini stretti è fragile.

Il controllo robusto, in un certo senso, generalizza questa idea. Invece di due numeri scalari su un anello a un ingresso e un’uscita, dà una garanzia su un intorno di incertezza descritto in modo molto più ricco, e per sistemi multivariabili — con più ingressi e più uscite intrecciati — dove il concetto di “margine” come scalare non basta più. Ma l’intuizione di base è già tutta qui: robustezza è distanza dal confine dell’instabilità, e quella distanza si può, e si deve, misurare con un numero invece che con una sensazione.

Incertezza strutturata e non strutturata: due modi di disegnare la fascia

Il controllo robusto deve dichiarare l’intorno di incertezza — la fascia attorno alla mappa. Lo fa in due modi, e la distinzione è centrale perché determina quale metodo di progetto si usa.

Il primo modo è l’incertezza parametrica, detta anche strutturata. La struttura del modello — la forma delle equazioni — è fissa e nota. Ciò che è incerto sono i numeri dentro le equazioni, e si sa che stanno dentro intervalli noti. La massa è fra 2 e 3 kg. La costante elastica fra 100 e 120 N/m. Lo smorzamento fra 0,1 e 0,3. Si chiama “strutturata” perché si sa dove, nel modello, è collocata l’incertezza: in questo parametro, in quell’altro, dentro questi intervalli. È una descrizione informativa: dichiara molto su cosa può e cosa non può succedere.

Il secondo modo è l’incertezza non strutturata. Qui non si sa nemmeno la forma di ciò che manca. Si dichiara solo che esiste una dinamica ignota — i modi non modellati, le flessibilità, i ritardi approssimati — e che la sua “dimensione” è limitata: il suo effetto sulla risposta in frequenza non supera un certo profilo noto. È una scatola con un coperchio sopra: si sa quanto è grande la scatola, non com’è fatta dentro. Si chiama “non strutturata” perché non si attribuisce l’incertezza a un parametro specifico: la si tiene tutta insieme in un unico blocco limitato in norma.

Le due descrizioni hanno un trade-off netto. L’incertezza non strutturata è onesta: non finge di sapere ciò che non sa, e cattura davvero le dinamiche di cui non hai un modello. Ma è conservativa: dentro quell’unica scatola finiscono anche modelli che non possono fisicamente accadere — il coperchio racchiude più di quanto serva — e il controllore paga, in prestazione ceduta, per proteggersi anche da quei modelli impossibili.

L’incertezza parametrica, all’opposto, è meno conservativa — descrive solo ciò che può davvero succedere, gli intervalli sono stretti attorno alla fisica reale — ma chiede di sapere di più sul sistema: bisogna conoscerne la struttura e gli intervalli dei parametri. Nella pratica le due descrizioni si usano spesso insieme, in una stessa fascia: i parametri ben caratterizzati entrano come incertezza strutturata, e ciò che resta — i modi veloci, le flessibilità — finisce in un blocco non strutturato. È il caso del controllore di volo dell’Esempio 3.

Da questo trade-off nascono due famiglie di metodi, che vedremo nella sezione seguente: il controllo H-infinito, tagliato sull’incertezza non strutturata, e la mu-synthesis, che sfrutta la struttura quando la si conosce.

La meccanica, a livello concettuale

Questo capitolo resta a livello concettuale: niente equazioni di Riccati, niente realizzazione in spazio di stato del controllore ottimo. Ma lo schema di ragionamento del controllo robusto si può seguire con precisione anche senza la matematica pesante, ed è quello che conta per capire il resto.

La struttura P-Delta

Il punto di partenza è un modo di riscrivere il sistema incerto. L’idea è semplice e potente: si separa ciò che si sa da ciò che non si sa, e si mettono le due cose in due scatole distinte.

Tutto ciò che si sa — la parte nominale del plant, il controllore, le interconnessioni — si raccoglie in un unico blocco noto, chiamato per convenzione $P$ (da plant generalizzato). Tutto ciò che non si sa — l’incertezza, in tutte le sue forme — si raccoglie in un secondo blocco, chiamato $\Delta$ (la lettera greca delta maiuscola).

Il punto cruciale: $\Delta$ non è un singolo sistema. È un insieme. È l’intorno di incertezza, cioè la collezione di tutti i $\Delta$ ammissibili. Tipicamente, dopo una normalizzazione che riscala le grandezze, l’insieme ammissibile è “tutti i $\Delta$ con norma non superiore a uno”, che si scrive $\|\Delta\| \le 1$ . La norma di $\Delta$ qui misura “quanto è grande” l’incertezza; chiedere che stia sotto uno significa aver impacchettato dentro quel numero tutta la dimensione della fascia.

Il sistema incerto, allora, è la connessione in anello di $P$ e di un $\Delta$ qualsiasi pescato dall’insieme. Questa è la struttura P-Delta, ed è la rappresentazione canonica di tutti i problemi di controllo robusto.

La forza di questa riscrittura è che riconduce ogni tipo di incertezza — parametrica o non strutturata, una o tante sorgenti — a un unico schema: un blocco noto, un blocco incerto limitato, chiusi in anello. Un problema di controllo robusto, qualunque sia la sua origine fisica, si traduce sempre in questa forma, e tutti i metodi — H-infinito, mu-synthesis — lavorano su di essa. È il motivo per cui vale la pena impararla anche solo a livello di immagine.

Le due domande: stabilità robusta e prestazione robusta

Con la struttura P-Delta in mano, il controllo robusto pone due domande, in ordine di forza crescente.

La prima è la stabilità robusta. L’anello chiuso resta stabile per ogni $\Delta$ dentro l’insieme? Non per il $\Delta$ nominale — che di solito è zero, nessuna incertezza — ma per tutti, anche per il peggiore.

La risposta la dà il small-gain theorem, il teorema formulato da Zames negli anni Sessanta. In parole: se metti in anello due sistemi stabili e il guadagno del giro — quanto un segnale viene amplificato facendo un giro completo dell’anello — resta sotto uno a ogni frequenza, l’anello è stabile. L’intuizione: se un disturbo, girando nell’anello, torna sempre più piccolo di com’era partito, non può crescere all’infinito, e il sistema non diverge. Applicato alla struttura P-Delta: l’anello incerto è robustamente stabile se il guadagno del giro fra la parte nota $P$ e il blocco di incertezza $\Delta$ resta sotto uno per tutte le frequenze e per tutti i $\Delta$ dell’insieme.

Qui entra la norma H-infinito. La norma H-infinito di una funzione di trasferimento — la descrizione di come l’anello risponde frequenza per frequenza — è il picco del suo guadagno su tutte le frequenze. In parole povere: la risposta dell’anello nella frequenza peggiore, quella in cui amplifica di più.

Il small-gain theorem, tradotto in questo linguaggio, dice: l’anello incerto è robustamente stabile se la norma H-infinito della funzione “vista” dal blocco $\Delta$ sta sotto la soglia fissata dalla dimensione dell’incertezza. Stabilità robusta diventa un test su un singolo numero: un picco da tenere sotto controllo. È esattamente il motivo per cui la norma H-infinito è la grandezza centrale del controllo robusto lineare — perché trasforma una domanda su un infinito di modelli in una disuguaglianza su un solo numero.

La seconda domanda è la prestazione robusta, ed è più forte. Non chiede solo che l’anello resti in piedi per ogni $\Delta$ — chiede che mantenga prestazioni accettabili: errore piccolo, buona reiezione dei disturbi, risposta decente, per ogni modello dell’insieme. Un sistema può essere robustamente stabile e però, per il modello peggiore dell’intorno, rispondere malissimo: stabile ma lentissimo, stabile ma con un errore enorme. La prestazione robusta esclude anche questo.

Il modo elegante di trattare la prestazione robusta: si introduce un blocco di incertezza fittizio, che non rappresenta un’incertezza fisica ma l’obiettivo di prestazione, e si chiede la stabilità robusta del sistema allargato.

È un trucco di rappresentazione che riconduce la domanda forte — prestazione per tutti i modelli — alla domanda già risolta — stabilità per tutti i modelli — su un sistema con un blocco in più. È anche il punto in cui entra il valore singolare strutturato mu: la verifica della prestazione robusta si fa calcolando mu sul sistema allargato, e la mu-synthesis è il metodo che progetta il controllore per renderlo piccolo.

H-infinito e mu-synthesis

Da qui i due metodi. Il controllo H-infinito si chiama così perché il problema di progetto è: trovare il controllore che minimizza la norma H-infinito di una funzione di sensitività opportunamente pesata. Minimizzare quel picco significa rendere il sistema il meno sensibile possibile, alla frequenza peggiore, all’incertezza e ai disturbi.

Il controllo H-infinito assume tipicamente incertezza non strutturata limitata in norma, ed è relativamente diretto da calcolare — esistono soluzioni efficienti, ed è disponibile negli strumenti software standard del controllo. Il suo limite: proprio perché tratta l’incertezza come un unico blocco non strutturato, può essere conservativo — protegge anche da modelli che, conoscendo la struttura, sapresti impossibili.

La mu-synthesis (sintesi mu) è il passo che recupera la struttura. Quando l’incertezza è in parte parametrica — quando sai che certi blocchi di $\Delta$ corrispondono a parametri fisici dentro intervalli, e non a dinamiche ignote qualsiasi — trattarli tutti come un unico blocco non strutturato butta via informazione e paga in conservatività.

La mu-synthesis tiene conto della struttura del blocco $\Delta$ tramite uno strumento chiamato valore singolare strutturato, indicato con la lettera greca mu. Il valore singolare strutturato è, in sostanza, la versione “consapevole della struttura” del picco H-infinito: misura quanto l’incertezza strutturata può avvicinare l’anello all’instabilità, senza contare i modelli che la struttura esclude.

La mu-synthesis è meno conservativa dell’H-infinito puro: sfruttando la struttura, non si protegge da modelli impossibili. Ma è più costosa: il valore singolare strutturato non si calcola in forma chiusa, e la sintesi del controllore si fa con un’iterazione — chiamata D-K iteration — che alterna due passi e che, va detto onestamente, non ha garanzia di convergere all’ottimo globale. È un metodo potente e un metodo imperfetto: lo si sceglie quando la conservatività dell’H-infinito costa troppo e si conosce abbastanza la struttura dell’incertezza per sfruttarla.

Il test di stabilità robusta su un esempio concettuale

Conviene vedere lo schema in azione su un caso semplice, senza calcoli, perché rende concreta la condizione del small-gain theorem.

Il modo più comune di descrivere un’incertezza non strutturata è l’incertezza moltiplicativa. Si scrive che il plant vero non è il plant nominale, ma il plant nominale moltiplicato per un fattore di errore. Quel fattore di errore è $1$ più un termine incerto $\Delta$ pesato da una funzione $W$ — un profilo che dice quanto grande può essere l’errore a ogni frequenza.

L’idea fisica del peso $W$ è importante. Alle basse frequenze il modello di solito è buono: hai misurato bene il comportamento lento, l’errore relativo è piccolo, e $W$ vale poco. Alle alte frequenze il modello è cattivo: lì vivono i modi non modellati, le flessibilità, i ritardi approssimati, e l’errore relativo può avvicinarsi a $1$ o superarlo — $W$ vale molto. Il profilo di $W$ che cresce con la frequenza è il modo onesto di dire “il mio modello vale alle basse frequenze e non vale alle alte”.

Il small-gain theorem, applicato a questa descrizione, dà una condizione di stabilità robusta che si legge in parole povere così: l’anello chiuso resta stabile per ogni errore moltiplicativo dentro il profilo $W$ se, a ogni frequenza, il prodotto fra il peso $W$ e una certa funzione dell’anello chiuso — la funzione di sensitività complementare, che misura quanto l’anello insegue il segnale — sta sotto uno.

Questa condizione ha una lettura di progetto immediata, ed è il cuore operativo del controllo robusto in frequenza. Dove l’incertezza è grande — alle alte frequenze, $W$ grande — la funzione dell’anello chiuso deve essere piccola: l’anello deve “smettere di inseguire”, non amplificare ciò che non conosce. Dove l’incertezza è piccola — alle basse frequenze — l’anello può essere aggressivo e inseguire bene.

Il progetto robusto, allora, è la scelta di quanto in fretta l’anello deve mollare la presa salendo in frequenza: abbastanza presto da stare sotto la soglia dove il modello diventa inaffidabile. È esattamente il trade-off performance-robustezza della sezione seguente, scritto nel linguaggio della frequenza.

Un numero per fissare l’idea. Supponi che, a una certa frequenza alta, il peso $W$ valga $0{,}8$ — l’errore relativo del modello lì può arrivare all’ottanta per cento. La condizione di stabilità robusta chiede che il prodotto fra $W$ e la funzione dell’anello chiuso stia sotto $1$ : quindi a quella frequenza la funzione dell’anello chiuso deve restare sotto $1 / 0{,}8 = 1{,}25$ .

Se invece a quella frequenza $W$ valesse $2$ — un errore di modello che può raddoppiare la risposta — la funzione dell’anello chiuso dovrebbe stare sotto $0{,}5$ : l’anello sarebbe costretto a inseguire molto meno. Più grande è l’incertezza dichiarata a una frequenza, più piccola la presa che l’anello può permettersi lì. La condizione del small-gain theorem non è un’astrazione: è un vincolo numerico, frequenza per frequenza, su quanto il controllore può essere aggressivo.

Il trade-off fondamentale: performance contro robustezza

Tutto il capitolo converge qui. Il controllo robusto vive di un trade-off, e questo trade-off non è un difetto eliminabile con più ingegno: è strutturale.

Un controllore aggressivo — guadagni alti, banda larga, risposta rapida — va benissimo sul modello nominale. Insegue velocemente il setpoint, tiene l’errore piccolo, reagisce subito ai disturbi. Sul modello, è splendido.

Ma il controllore aggressivo è fragile: i suoi margini sono stretti, e una piccola discrepanza fra modello e sistema vero — un ritardo non previsto, un modo di vibrazione eccitato, un parametro fuori dalla stima — lo manda in oscillazione o in instabilità. È il controllore che funziona in laboratorio e si rompe sul campo.

Un controllore robusto fa il contrario. Rinuncia a parte della prestazione di picco — risposta più lenta, guadagni più prudenti, banda più stretta — per comprare margine, e quindi tolleranza all’incertezza. Sul modello nominale è quasi sempre peggiore del controllore aggressivo: insegue più lentamente, ha un errore transitorio più grande. Ma non si rompe per nessun modello dentro l’intorno dichiarato.

Il punto duro è questo: non esiste un controllore che sia al tempo stesso il più performante sul nominale e il più robusto all’incertezza. La prestazione di picco e la robustezza sono in tensione, e il progetto robusto è la scelta consapevole di un punto su questa frontiera.

La domanda di progetto, allora, non è “quanto posso essere bravo?”. È “quanta prestazione di picco sono disposto a cedere per non rompermi mai?”. È una domanda diversa, e ha risposte diverse a seconda di cosa costa il fallimento.

Per un bruciatore industriale, dove un transitorio brutto costa poco e il fallimento non è catastrofico, si può stare aggressivi: il lato della frontiera ad alta prestazione. Per un controllore di volo, per un robot che maneggia un carico vicino a una persona, per un convertitore di potenza, si sceglie il lato robusto: si paga la prestazione, si compra la garanzia. Il controllo robusto non dice quale punto scegliere — quello è una decisione di ingegneria che dipende dalle conseguenze — ma dà gli strumenti per scegliere il punto sapendo cosa si sta scambiando.

Questo trade-off non resta confinato al controllo. Ricompare nel machine learning, e questa volta il legame è una parentela concettuale solida — non una metafora vaga, ma neppure una identità.

Un modello molto fittato sui dati di addestramento — bassa loss in training — è spesso fragile fuori distribuzione, esattamente come un controllore molto fittato sul modello nominale è fragile fuori dal nominale. È il fenomeno dell’overfitting, e si inquadra nel trade-off bias-varianza.

La regolarizzazione in machine learning — penalizzare la complessità del modello, fermare l’addestramento prima, aggiungere rumore — gioca il ruolo che gioca la scelta di margine nel controllo: si rinuncia a un po’ di aderenza ai dati visti per guadagnare comportamento fuori da essi. Lo schema è lo stesso: cedere prestazione sul caso nominale per comprare tenuta sul resto. È una parentela concettuale, da maneggiare come tale — ma è abbastanza solida da rendere il controllo robusto una buona lente per chi pensa alla generalizzazione di un modello.

Esempi

Tre esempi eterogenei, scelti per coprire tre registri diversi: uno numerico, che mostra come un margine si confronta con un’incertezza; uno in codice, che porta il controllo robusto dentro un anello di feedback fatto di software; uno scenario reale, che mostra le due forme di incertezza al lavoro insieme su un sistema fisico complesso.

Esempio 1 — numerico: leggere un margine di guadagno

Un anello di controllo ha, alla frequenza di crossover — la frequenza dove il guadagno dell’anello vale esattamente 1, cioè 0 dB — una certa fase. Supponi che il progetto dichiari un margine di guadagno di 6 dB.

I decibel sono una scala logaritmica: $6 \text{ dB}$ corrisponde a un fattore $2$ in ampiezza (la regola pratica: ogni 6 dB raddoppiano l’ampiezza, ogni 20 dB la decuplicano). Quindi il margine di guadagno di 6 dB dice: il guadagno reale dell’anello può arrivare al doppio del valore nominale prima che il punto critico — il punto $-1$ nel piano di Nyquist, la soglia dell’instabilità — venga raggiunto.

Ora confronta questo con l’incertezza dichiarata sul plant. È il passo che trasforma un numero astratto in una decisione di progetto.

Caso A: l’incertezza è “il guadagno del plant può variare del più o meno trenta per cento”. Il caso peggiore è un guadagno a $1{,}3$ volte il nominale. $1{,}3$ è ben sotto $2$ , quindi 6 dB di margine coprono l’incertezza con abbondanza, e l’anello è robustamente stabile rispetto a quella variazione. Il progetto va bene così.

Caso B: l’incertezza è “in certe condizioni di carico il guadagno del plant può triplicare”. Il caso peggiore è $3$ volte il nominale. $3$ è sopra $2$ , quindi 6 dB non bastano: esiste un modello dentro l’intorno dichiarato per cui l’anello diventa instabile. Il controllore “sembra andare” sul nominale e si rompe nel caso di carico estremo.

La conclusione operativa: nel caso B il margine va riprogettato — guadagni più prudenti, banda più stretta — per portarlo sopra i $9{,}5$ dB circa che corrispondono al fattore $3$ in decibel, pagando in prestazione. È il trade-off del capitolo ridotto a un confronto fra due numeri: la dimensione dell’incertezza da una parte, il margine disponibile dall’altra. Se il secondo non copre la prima, si cede prestazione finché lo copre.

Esempio 2 — codice: uno scudo robusto su un autoscaler software

Un anello di feedback fatto di software ha la stessa struttura di un anello di controllo fisico, e lo stesso problema. Prendi un autoscaler: un componente che aggiunge e toglie repliche di un servizio per inseguire un carico, con l’obiettivo di tenere la latenza vicino a un target.

Il “modello” implicito dell’autoscaler è la relazione fra numero di repliche e latenza. Quel modello non è esatto e cambia nel tempo: cache calde o fredde, vicini rumorosi sulla stessa macchina, carico con composizione variabile. È incertezza, esattamente come quella di un plant fisico — solo che qui nessuno l’ha mai scritta come un modello, e il rischio è proprio non accorgersi che c’è.

Un autoscaler aggressivo — che reagisce forte a ogni scostamento — oscilla: aggiunge troppe repliche, la latenza scende sotto il target, ne toglie troppe, la latenza risale, ping-pong. È un anello senza margine, che entra in risonanza con il proprio ritardo (le repliche non partono istantaneamente). La versione robusta cede prontezza di inseguimento per comprare margine:

# autoscaler robusto: guadagno conservativo + banda morta + clamp
# rinuncia a inseguire ogni fluttuazione (prestazione di picco)
# per non entrare in risonanza col proprio ritardo (robustezza)
def passo_autoscaler(latenza, target, repliche):
    errore = latenza - target
    if abs(errore) < banda_morta:        # rumore: non reagire affatto
        return repliche
    delta = guadagno_prudente * errore   # guadagno basso = margine ampio
    delta = clamp(delta, -1, +1)         # al massimo una replica per passo
    return repliche + nuovo_intero(delta)

Tre scelte, tutte robuste, e vale la pena leggerle una per una.

La banda morta ignora gli scostamenti piccoli: sotto una soglia, l’autoscaler non reagisce, perché quegli scostamenti sono rumore e inseguirli significa amplificarlo. Il guadagno prudente è basso: l’anello corregge piano, e un guadagno basso vuol dire margine ampio — è la traduzione diretta del margine di guadagno dell’Esempio 1. Il clamp limita la correzione a una replica per passo: nessuno scatto improvviso che il ritardo del sistema — il tempo che una replica impiega a partire e scaldarsi — non riesce a seguire.

Il risultato insegue il carico più lentamente di un autoscaler aggressivo — meno prestazione — ma non oscilla anche se il modello latenza-contro-repliche è impreciso e variabile — più robustezza. È il trade-off del capitolo, in un anello che non ha niente di fisico. E il punto pratico per chi costruisce sistemi: non serve sapere il controllo H-infinito per applicarlo. Serve riconoscere che l’autoscaler è un anello di controllo con un modello incerto, e ragionare di conseguenza su margine e prudenza.

Esempio 3 — scenario reale: il controllore di volo e l’inviluppo

Un controllore di assetto di un velivolo è progettato su un modello aerodinamico. Quel modello dipende da velocità, quota, carico, configurazione delle superfici — e nessuna di queste grandezze è un numero fisso. Il velivolo non vola in un punto: vola in un inviluppo, una regione di condizioni operative. In crociera ad alta quota il modello ha certi coefficienti; in salita ripida a bassa velocità ne ha altri; con i serbatoi pieni la massa e il baricentro sono diversi che con i serbatoi quasi vuoti.

Un controllore ottimizzato solo sulla condizione di crociera nominale può volare benissimo in crociera e diventare fragile fuori da essa — proprio il caso del controllore aggressivo, fragile fuori dal modello.

Il progetto robusto dichiara invece l’intorno di incertezza in modo esplicito, e qui si vedono insieme le due forme di incertezza viste prima. La prima componente è parametrica: i coefficienti aerodinamici stanno in intervalli noti, che coprono tutto l’inviluppo. La seconda è non strutturata: un blocco che cattura i modi flessibili della fusoliera — la struttura non è perfettamente rigida, vibra — che non sono modellati nel dettaglio ma di cui si conosce la dimensione complessiva.

Su questo intorno a due componenti, la mu-synthesis produce un controllore di cui si dimostra che mantiene stabilità e qualità di volo accettabile per ogni punto dell’inviluppo, non solo per la crociera. Non è un caso che il controllo robusto, e la mu-synthesis in particolare, siano maturati in larga parte su problemi aerospaziali: è un dominio dove l’inviluppo è ampio, il modello varia molto, e il fallimento è catastrofico. Tre condizioni che, messe insieme, rendono il “progetta per il nominale e spera” inaccettabile.

Robusto contro adattivo: una distinzione da non perdere

C’è un’altra risposta al fatto che il modello non è esatto, ed è facile confonderla con il controllo robusto. È il controllo adattivo.

I due affrontano lo stesso problema — il modello non è esatto — in modi opposti, e tenerli distinti è parte della disciplina di questo capitolo. Il controllo adattivo avrà un capitolo proprio; qui basta la distinzione netta, perché usare i due termini come sinonimi è un errore diffuso.

Il controllo robusto lavora con un controllore fisso. Lo progetti una volta, sapendo che il modello è incerto, e non lo cambi più. La robustezza viene tutta dall’aver pianificato in anticipo per il caso peggiore dentro l’intorno.

Il vantaggio del controllore fisso è la semplicità e la prevedibilità: un controllore solo, un comportamento garantito, una dimostrazione formale che vale prima dell’accensione. Lo svantaggio è la conservatività: il controllore paga sempre il prezzo del caso peggiore, anche quando il sistema vero è quello “facile” dentro l’intorno. Se la natura, in questa partita, gioca male, tu hai comunque pagato per difenderti dal suo gioco migliore.

Il controllo adattivo lavora con un controllore che cambia. Il controllore stima in tempo reale i parametri del sistema — guarda come il plant risponde e aggiorna la propria idea di com’è fatto — e si riconfigura di conseguenza.

Il vantaggio del controllore adattivo è che, se il sistema vero è benigno, converge verso il controllore quasi-ottimo per quel sistema, senza pagare il caso peggiore. Lo svantaggio: la fase di stima introduce transitori, può essere ingannata dal rumore o dai disturbi — un disturbo scambiato per un cambiamento del sistema porta a un aggiornamento sbagliato — e dimostrarne la stabilità è considerevolmente più delicato che per un controllore fisso.

Lo slogan che riassume la distinzione: il controllo robusto sopporta l’incertezza, il controllo adattivo la riduce.

I due non sono nemici — si combinano nel controllo adattivo robusto, dove un nucleo robusto tiene la stabilità mentre uno strato adattivo affina la prestazione — ma chiamarli con lo stesso nome, o usarli come sinonimi, è uno degli errori più comuni di chi entra nel campo.

Applicazioni pratiche

Il controllo robusto compare ben oltre la sua nicchia aerospaziale di origine.

Aerospazio e automotive. È il dominio nativo: controllo di volo, controllo di assetto, sistemi di stabilità dei veicoli. L’inviluppo operativo è ampio, il modello varia molto da una condizione all’altra, il fallimento è costoso. La mu-synthesis è maturata su questi problemi proprio perché qui la conservatività dell’H-infinito puro pesa, e conoscere la struttura dell’incertezza — quali coefficienti, quali intervalli — ripaga lo sforzo di calcolo in più.

Convertitori di potenza ed elettronica. Un convertitore alimenta un carico che cambia: l’impedenza vista dal convertitore varia con ciò che gli è attaccato. L’incertezza è intrinseca al funzionamento, non un difetto di modellazione. Si progetta robusto per garantire stabilità su tutto il campo di carico previsto, non solo per il carico nominale.

Robotica e processi industriali. Un braccio robotico che maneggia carichi di peso diverso vede la propria dinamica cambiare a ogni presa: il carico è un parametro incerto, esattamente nel senso dell’incertezza strutturata. Lo stesso vale per un processo industriale i cui parametri derivano nel tempo — un reattore chimico la cui resa cambia con l’usura del catalizzatore. In tutti questi casi il controllo robusto produce un controllore unico, valido per tutta la gamma di carichi o di condizioni, evitando di dover riprogettare e ritarare a ogni variazione.

Anelli di feedback fatti di software. È l’applicazione più vicina a chi costruisce sistemi AI. Autoscaler, controllori di concorrenza che alzano e abbassano un limite di richieste in volo, rate limiter adattivi, meccanismi che regolano la dimensione di un batch per tenere una latenza obiettivo: tutti hanno la struttura di un anello di controllo, tutti hanno un “modello” implicito impreciso e variabile.

La scelta di guadagni prudenti, bande morte e limiti sulla velocità di correzione — come nell’Esempio 2 — è controllo robusto applicato a un anello che non ha niente di fisico. Non sempre si ha un modello abbastanza buono per un progetto H-infinito formale; ma il ragionamento “quanto margine sto comprando, e contro quale incertezza” è già una guida concreta, e spesso è tutto ciò che serve per evitare l’oscillazione.

Sistemi AI affidabili. Il worst-case thinking del controllo robusto — chiedersi non “funziona nel caso felice?” ma “qual è il caso peggiore plausibile, e il sistema regge?” — è un metodo di progetto trasferibile, ed è il tema della sezione che segue.

Il ponte verso l’AI e l’agent coding

La robustezza è un tema centrale del machine learning e dell’ingegneria degli agenti, e diversi suoi sotto-temi hanno una parentela concettuale con il controllo robusto. La parola “parentela” è scelta con cura: prima di percorrere il ponte, fissiamo la regola che lo governa, perché è esattamente il punto su cui il ragionamento scivola più facilmente.

Tutti i legami che seguono sono analogie o parentele concettuali — condivisione di uno schema di ragionamento, lo schema min-max del “progetta per il caso peggiore dentro un insieme”.

Nessuno di essi è una filiazione storica: la distributionally robust optimization e l’adversarial training non discendono dal controllo robusto, non sono stati costruiti citandolo come progenitore; hanno radici proprie nell’ottimizzazione e nella statistica robusta. E nessuno è una identità matematica: lo schema è condiviso, gli oggetti su cui si applica no. Marcare ogni legame con la sua classe non è pedanteria — è ciò che separa un ponte solido da un’analogia che, scivolando, finisce per dire il falso.

Detta la regola, ecco il ponte.

Distribution shift. Un modello di machine learning è addestrato su una distribuzione di dati e poi usato su un’altra, leggermente diversa — fotografie scattate con un’altra fotocamera, testo di un altro registro, utenti di un altro paese. È lo stesso pattern del controllo robusto: progettato su un modello, usato su un sistema diverso.

La distributionally robust optimization (DRO) rende esplicita la parentela. La DRO non ottimizza la loss sulla distribuzione empirica dei dati di training: la ottimizza sul caso peggiore dentro un insieme di distribuzioni possibili — un ambiguity set, definito per esempio come “tutte le distribuzioni a distanza limitata, in una metrica come la distanza di Wasserstein, da quella empirica”.

L’analogia con il controllo robusto è diretta, e va dichiarata per quello che è: l‘“insieme di modelli possibili” del controllo robusto e l‘“insieme di distribuzioni possibili” della DRO giocano lo stesso ruolo, e in entrambi i casi si ottimizza il min-max contro un avversario che pesca il peggior elemento dall’insieme. Parentela concettuale, stesso schema; oggetti diversi — una dinamica con una manopola di controllo contro una distribuzione di dati senza nessuna manopola.

Robustezza agli esempi avversari. Un avversario sceglie una perturbazione piccola e mirata di un input — qualche pixel impercettibile, qualche carattere — per far sbagliare il modello. L’adversarial training addestra il modello contro questo avversario: a ogni passo, prima si cerca la perturbazione peggiore, poi si aggiorna il modello per resistervi.

È, di nuovo, un gioco min-max — esattamente lo schema del “caso peggiore come avversario” del secondo angolo di questo capitolo. Parentela strutturale; non identità: l’avversario del controllo robusto sceglie un modello dinamico, quello dell’adversarial training una perturbazione di un input. Il tema avrà un capitolo dedicato (adversarial-examples (in preparazione)).

Il trade-off performance contro robustezza che ricompare. Già detto nella sezione sul trade-off, e qui ribadito perché è il ponte più solido: un modello molto fittato sui dati di training è fragile fuori distribuzione, come un controllore molto fittato sul nominale è fragile fuori dal nominale. È l’overfitting, inquadrato nel trade-off bias-varianza.

C’è anche, nel machine learning, evidenza di un trade-off misurato fra accuratezza standard e robustezza avversaria — addestrare per resistere agli esempi avversari tende a far scendere l’accuratezza sugli input puliti, ed è un risultato documentato in letteratura. È lo stesso movimento della frontiera della figura 5: si cede su un asse per guadagnare sull’altro.

Robustezza dei prompt e degli agenti. Un prompt o un agente che funziona solo in condizioni nominali — input ben formati, tool che rispondono come previsto, ambiente stabile — è fragile come un controllore nominale. Un agente robusto è progettato per il caso peggiore plausibile: tool che falliscono o restituiscono output malformati, contesti inattesi, ambienti che cambiano sotto i piedi durante l’esecuzione.

Il worst-case thinking del controllo robusto è qui una guida di progetto diretta. Non chiedersi solo “il flusso felice funziona?”, ma “qual è il caso peggiore plausibile — il tool va in timeout, l’API cambia formato, il file non c’è — e l’agente regge?”. È lo stesso atto mentale di chi disegna l’intorno di incertezza prima di progettare il controllore. La parola “plausibile” conta: come l’intorno di incertezza di un controllore non copre disturbi infiniti, il caso peggiore di un agente non è “qualsiasi cosa immaginabile” — è il peggiore fra quelli realistici, e dichiararlo è già metà del progetto.

Il margine di sicurezza nei guardrail. Un guardrail — un controllo automatico che blocca o segnala un comportamento indesiderato di un sistema AI — tarato esattamente al limite del comportamento accettabile è fragile come un anello senza margine di fase: basta un piccolo errore di stima e lo si oltrepassa.

Un guardrail con margine — una zona cuscinetto fra “ancora accettabile” e “intervieni” — è l’analogo del margine di stabilità del controllo. Il controllo robusto dà il vocabolario per ragionare su quanto debba essere ampio quel cuscinetto: tanto quanto l’incertezza sulla misura e sulla soglia. È un’analogia, e come tale va usata — ma è un’analogia che orienta una decisione di progetto concreta, perché trasforma “metti un guardrail” in “metti un guardrail con un margine dimensionato sull’incertezza che hai”.

Dove si rompe

Il controllo robusto è uno strumento solido, ma ha confini netti e modi caratteristici di essere frainteso. Passarli in rassegna è parte del capitolo quanto i meccanismi.

“Robusto” non vuol dire “migliore”. È il fraintendimento di base, e va isolato. Un controllore robusto, sul modello nominale, è quasi sempre peggiore di uno aggressivo: insegue più lentamente, ha un transitorio più brutto, un errore più grande. La robustezza non è una qualità in più gratuita: è prestazione di picco scambiata con tolleranza all’incertezza. Chi vende “robusto” come sinonimo di “performante” sta nascondendo il trade-off, non superandolo.

La garanzia vale quanto l’intorno di incertezza dichiarato. Tutto il controllo robusto poggia su una premessa: che il sistema vero stia davvero dentro l’intorno di incertezza che hai disegnato. Se il sistema reale esce dalla fascia — un parametro fuori dall’intervallo che credevi esaustivo, una dinamica non modellata più grande del blocco che le avevi assegnato — la garanzia salta, e salta senza preavviso.

Il punto da capire è che il controllo robusto non elimina il problema della modellazione: lo sposta. Invece di dover indovinare un modello esatto, devi indovinare un intorno che contenga il modello vero. È un compito più facile — un intervallo è più facile da azzeccare di un valore puntuale — ma non è un compito banale.

Un intorno disegnato male dà una garanzia che sembra valere e non vale. E qui c’è un tranello aggiuntivo: l’intorno disegnato troppo stretto è pericoloso quanto un modello nominale sbagliato, perché illude di aver coperto un’incertezza che in realtà è più grande. La caratterizzazione dell’incertezza — quanto vale ogni intervallo, quanto è grande ogni blocco non strutturato — è un lavoro di ingegneria a sé, e il controllo robusto è affidabile solo quanto quel lavoro.

La conservatività è un costo reale, non un dettaglio. Progettare per il caso peggiore significa, per definizione, pagare per modelli che potrebbero non realizzarsi mai. Con incertezza non strutturata il costo è massimo: l’unico blocco limitato in norma racchiude anche modelli fisicamente impossibili, e il controllore cede prestazione per difendersi pure da quelli. Un controllo robusto progettato con un intorno troppo largo — per prudenza, o per pigrizia nel caratterizzare meglio l’incertezza — può essere così lento da risultare inutilizzabile. Robusto e inutile è un esito possibile.

Stabilità robusta non basta. È una confusione frequente. La stabilità robusta garantisce solo che il sistema non diverge per nessun modello dell’intorno. Non dice niente su quanto bene lavora. Un sistema può essere robustamente stabile e, per il modello peggiore dell’intorno, rispondere malissimo — stabile ma lentissimo, stabile ma con un errore enorme che non si chiude mai. La prestazione robusta è una richiesta separata e più forte, e va verificata a parte. “È robustamente stabile” non è sinonimo di “funziona bene”.

H-infinito e mu-synthesis non sono la stessa cosa. Si tende a confonderli perché vivono nella stessa famiglia. Ma l’H-infinito tratta tipicamente incertezza non strutturata, è diretto da calcolare, ed è conservativo. La mu-synthesis sfrutta la struttura dell’incertezza, è meno conservativa, ma è più costosa e — questo va detto apertamente — la sua D-K iteration non ha garanzia di convergere all’ottimo globale. Scegliere mu-synthesis “perché è meglio” senza valutare se si conosce abbastanza la struttura dell’incertezza, e senza tenere conto del costo di calcolo, è una scelta mal posta.

“L’LQG è ottimo, quindi è buono” è un passaggio invalido. Lo dice la nota di Doyle del 1978, ed è il cuore storico del capitolo. L’ottimalità LQG è ottimalità rispetto al modello nominale. Non porta in dote alcun margine di robustezza — anzi, Doyle mostra che un LQG ottimo può non avere nessun margine. Concludere da “questo controllore è ottimo” che “questo controllore è affidabile” salta esattamente la distinzione che il controllo robusto esiste per fare: ottimalità rispetto a un modello e robustezza rispetto all’incertezza del modello sono cose diverse, e la prima non implica la seconda.

Il ponte verso il machine learning è analogia, e scivola con facilità. È il fraintendimento che questo capitolo, vivendo in una wiki sull’AI, rischia di indurre più di ogni altro. “La distributionally robust optimization è il controllo robusto applicato ai dati” è falso come identità e come filiazione.

È vera, e utile, solo come parentela concettuale: lo schema min-max del progetto per il caso peggiore è condiviso; gli oggetti — una dinamica con una manopola di controllo da una parte, una distribuzione di dati senza nessuna manopola dall’altra — sono diversi, e le tecniche hanno radici storiche autonome. Usare la stessa immagine — “progetta per un insieme, non per un punto” — per i due casi è legittimo e produttivo, a patto di sapere, ogni volta, se si sta maneggiando un’analogia o un teorema. Scambiare la parentela per l’identità è il modo più rapido di costruire un’argomentazione che sembra rigorosa e non lo è.

La robustezza non protegge da un disturbo arbitrariamente grande. L’intorno di incertezza, e i disturbi previsti, hanno una dimensione dichiarata. Un disturbo più grande di quello previsto — un guasto, un evento fuori scala — può portare il sistema fuori dalla regione che il progetto robusto copre.

Il controllo robusto allarga il margine di sicurezza; non lo rende infinito. Per gli eventi fuori scala servono altri strati: rilevazione di guasti, riconfigurazione, fallback. Il controllo robusto è uno strato della difesa, non l’intera difesa — e progettarlo come se lo fosse è un errore di architettura, non di taratura.

Il modello dell’incertezza è esso stesso incerto. C’è un’ironia annidata nel metodo. Il controllo robusto tratta l’incertezza sul plant, ma per farlo ha bisogno di un modello dell’incertezza — gli intervalli dei parametri, il profilo del peso $W$ . Quel modello è anch’esso una stima, e può essere sbagliato.

Si è solo spostato il problema di un livello: dal “quanto è esatto il modello del plant?” al “quanto è esatta la mia descrizione di quanto è inesatto il modello del plant?”. Non è un’obiezione che invalida il metodo — descrivere un intervallo resta più facile e più onesto che fingere un valore esatto — ma è una ragione per non leggere la garanzia del controllo robusto come una certezza assoluta. È una garanzia condizionata, come tutte.

L’incertezza non strutturata può nascondere un sistema più semplice del previsto. Trattare tutta l’incertezza come un unico blocco non strutturato è prudente, ma a volte è anche pigro. Capita che, dietro a un blocco non strutturato grande, ci sia in realtà un’incertezza quasi tutta parametrica, ben caratterizzabile, che renderebbe il progetto molto meno conservativo. La scelta fra strutturata e non strutturata non è solo tecnica: è anche una scelta su quanto si è disposti a investire nella caratterizzazione del sistema. Saltare quell’investimento e rifugiarsi nel blocco non strutturato è comodo, e si paga in prestazione ceduta senza necessità.

Collegamenti

Controllare un sistema: plant, controller, sensore, attuatore — fissa il vocabolario di plant, modello, controllore, anello chiuso. Il controllo robusto rende esplicito che quel modello è incerto e progetta di conseguenza.
PID senza formalismo pesante — il PID è tarato per prove ed errori; i margini di stabilità misurano quanta incertezza quella taratura tollera, e il controllo robusto generalizza la misura.
Lyapunov a intuizione: energia che scende — il progetto via Lyapunov dà una garanzia di stabilità che vale quanto il modello; il controllo robusto chiede che la decrescita dell’energia generalizzata valga per ogni modello dell’intorno di incertezza.
Overshoot, delay, oscillazioni, divergenza — i modi tipici in cui un anello di feedback fallisce; i margini di guadagno e di fase misurano la distanza da quei fallimenti, e un ritardo non modellato mangia margine di fase.
Equilibrio, stabilità, attrattori — la teoria di stabilità su cui poggia la nozione di stabilità robusta: stabile per ogni modello dell’intorno, non solo per il nominale.
Minimax e alpha-beta — il controllo robusto è un gioco min-max: tu scegli il controllore, l’avversario sceglie il modello e il disturbo peggiori; la soluzione robusta è il punto di sella.
Il trade-off che non muore mai (bias-varianza) — il trade-off performance contro robustezza del controllo robusto è parente concettuale del trade-off bias-varianza: un modello molto fittato è fragile fuori dai dati visti.
controllo-vs-rl (in preparazione) — il capitolo che mette a confronto controllo classico e reinforcement learning; il controllo robusto e la robustezza delle policy apprese sono uno dei punti di contatto.
controllo-ottimo e model-predictive-control (in preparazione) — i capitoli vicini della Parte XI; il controllo ottimo è ciò che l’LQG rappresenta, e di cui Doyle ha mostrato la fragilità senza robustezza.
kalman-filter-intuizione (in preparazione) — il filtro di Kalman è la stima ottima dello stato; accoppiato all’LQR dà l’LQG, ed è proprio l’aggiunta del filtro che, nel controesempio di Doyle, distrugge i margini.
adversarial-examples e safety-engineering-intro (in preparazione) — la robustezza avversaria e i margini di sicurezza nei sistemi AI: parentele concettuali del controllo robusto sul versante machine learning.

Per andare oltre

J. C. Doyle, “Guaranteed Margins for LQG Regulators”, IEEE Transactions on Automatic Control, vol. 23, n. 4 (1978), pp. 756-757. La nota di due pagine che apre la “crisi” del controllo moderno: per controesempio, i regolatori LQG non hanno margini di robustezza garantiti.
G. Zames, “Feedback and Optimal Sensitivity: Model Reference Transformations, Multiplicative Seminorms, and Approximate Inverses”, IEEE Transactions on Automatic Control, vol. 26, n. 2 (1981), pp. 301-320. Il paper che riformula il controllo come minimizzazione della norma H-infinito: l’atto di nascita del controllo H-infinito.
K. Zhou, J. C. Doyle, K. Glover, Robust and Optimal Control (Prentice Hall, 1996). Il manuale di riferimento: norma H-infinito, small-gain theorem, valore singolare strutturato mu, struttura P-Delta, incertezza strutturata e non strutturata, mu-synthesis.
M. G. Safonov, “Origins of Robust Control: Early History and Future Speculations”, Annual Reviews in Control, vol. 36, n. 2 (2012), pp. 173-181. La ricostruzione storica della nascita del controllo robusto, dal periodo classico della sensitività al ruolo di Doyle e Zames.
J. C. Duchi, H. Namkoong, “Learning Models with Uniform Performance via Distributionally Robust Optimization”, arXiv:1810.08750 (2018). Sul versante machine learning: la DRO come ottimizzazione del caso peggiore su un insieme di distribuzioni — il parente concettuale del controllo robusto, da leggere tenendo ferma la distinzione di classe.