L’Intelligenza Artificiale non ha impiegato molto a farsi strada nella progettazione elettronica. Gli ingegneri utilizzano già interfacce in linguaggio naturale per ricercare informazioni, interrogare documentazione, confrontare componenti e persino generare elementi di un progetto.
Ma c’è una grande differenza fra uno strumento AI capace di rispondere a una domanda sulla progettazione e uno in grado di partecipare in modo significativo al flusso di lavoro di ingegnerizzazione.
Soprattutto nella progettazione di sistemi embedded, questa differenza conta. Perché una risposta plausibile non è sufficiente. Un progetto ha requisiti, vincoli e dipendenze.
Le decisioni a livello di architettura incidono su scelta dei componenti, interfacce, potenza, costi e, in ultima analisi, sul fatto che un sistema possa essere implementato o meno.
Per questo motivo, i prossimi sviluppi dell’IA nella progettazione elettronica riguarderanno meno la fornitura di risposte e più la progettazione agentica. Sistemi AI che possano capire un obiettivo, sviluppare un piano, eseguire singole attività e verificare i risultati rispetto ai requisiti iniziali.
Ne parla approfonditamente Tobias Pohl, Ceo e Co-fondatore di CELUS, nell’articolo che segue.
Chi è CELUS
Fondata da un gruppo di ingegneri e supportata da un consiglio direttivo composto da esperti di settore, CELUS riunisce produttori di componenti, distributori, fornitori di soluzioni EDA e ingegneri in tutto il settore della componentistica elettronica.
Propone soluzioni che trasformano la progettazione elettronica grazie alla sua piattaforma in cloud CELUS Design Platform, l’ambiente in cui avviene la scelta dei componenti.
Oltre 30.000 ingegneri in più di 100 Paesi progettano utilizzando una libreria di oltre 560.000 componenti, proseguendo poi il lavoro con Altium Designer, KiCad, Siemens EDA o Autodesk Fusion., per offrire cicli di sviluppo più brevi e nuove opportunità di ricavi.
Ha il proprio quartier generale a Monaco di Baviera, in Germania, e uffici a Porto in Portogallo e Austin in Texas.
Perché l’IA “single-shot” è limitata
L’attuale dibattito sull’IA generativa ruota attorno a un’interazione relativamente semplice: l’ingegnere sottopone una richiesta (prompt) e il modello genera una risposta.
Questo metodo può essere utile per attività discrete, ma raramente la progettazione elettronica funziona in questo modo!
Pensiamo alle fasi iniziali di un progetto embedded. Un progettista potrebbe sapere che il sistema richiede elaborazione, sensori, connettività wireless e un alimentatore particolare. Altri requisiti potrebbero invece essere ancora incerti.
Le prestazioni di elaborazione possono variare. Un’interfaccia di comunicazione potrebbe dipendere da un altro componente non ancora selezionato. Costi, disponibilità o requisiti del ciclo di vita potrebbero determinare l’eliminazione di un dispositivo tecnicamente fattibile.
Quindi, la progettazione procede in modo iterativo: se cambia un requisito, le conseguenze possono ricadere a cascata su altre scelte.
Attenzione al prompt
Un sistema IA che genera un’architettura partendo semplicemente da un prompt iniziale ha un problema: deve modificare la soluzione esistente? Ne deve generare una nuova oppure deve prima stabilire quali presupposti non sono più validi?
È qui che l’approccio agentico comincia a differenziarsi da un normale assistente AI. Invece di provare a produrre subito un risultato, l’agente può prima valutare ciò che conosce, quali supposizioni può fare e che cosa resta ignoto. Partendo da qui, può formulare un piano per risolvere il progetto.
Se in seguito un requisito cambia, il sistema può rivedere il suo ragionamento invece di gestire la nuova informazione semplicemente come un nuovo prompt isolato.
Prima pianificare, poi eseguire
La pianificazione può sembrare un piccolo dettaglio, ma nelle applicazioni di ingegneria è fondamentale. Prima di eseguire un’attività, l’agente può suddividere l’obiettivo in diversi passaggi e determinare quali informazioni e funzionalità sono richieste in ogni passaggio.
Diversi agenti specializzati o competenze specifiche possono poi svolgere le varie funzioni all’interno del piano.
Per un’architettura hardware embedded, ad esempio, una fase potrebbe essere l’interpretazione dei requisiti funzionali, un’altra l’identificazione di opzioni di implementazione idonee, un’altra ancora la valutazione se i blocchi proposti possano essere interconnessi correttamente.
Forse la cosa più importante è che l’intero processo dovrebbe essere visibile all’ingegnere. L’obiettivo non è creare una “scatola nera” autonoma dove si inserisce la descrizione del prodotto da un lato e viene sfornato un progetto insindacabile dall’altro.
Le scelte di progettazione comportano compromessi che non possono essere semplicemente delegati. Il progettista potrebbe preferire una determinata architettura in base alla sua esperienza, alla strategia di supply chain, ai requisiti di certificazione o a valutazioni che non sono pienamente riportate nella specifica originale.
L’AI agentica funge quindi più da co-pilota che da pilota automatico. Può svolgere più lavoro investigativo e ripetitivo, illustrando il suo piano e lasciando che l’ingegnere scelga se la direzione proposta è adeguata.
Dal linguaggio ai dati di progettazione
C’è un altro aspetto che distingue la progettazione elettronica dalle applicazioni più generiche dell’AI generativa: la conoscenza ingegneristica deve essere fruibile.
Una scheda tecnica può essere letta da una persona o interpretata da un modello linguistico. Ma stabilire che due componenti sono idonei non significa necessariamente che le loro interfacce elettriche siano compatibili, oltre al fatto che andranno individuati i circuiti necessari per connetterle.
Per fare tutto ciò servono informazioni ingegneristiche strutturate. In CELUS, ad esempio, le funzioni elettroniche possono essere rappresentate come blocchi leggibili a macchina detti CUBO.
Questi “mattoncini” contengono informazioni sui circuiti insieme a informazioni su interfacce, vincoli e regole di progettazione.
Il punto chiave non è semplicemente creare l’ennesima libreria di componenti.
Il punto è che l’intento progettuale e le relazioni tecniche diventano leggibili da una macchina. Una volta che le informazioni sono strutturate in questo modo, il software può agire sulla base di tali informazioni invece di limitarsi a recuperarle o riassumerle.
Pertanto, un agente IA può lavorare partendo da un requisito funzionale per arrivare a un’architettura elettronica, selezionando i blocchi adeguati e risolvendo le relazioni fra essi.
L’architettura così ottenuta può formare la base per gli schemi e lo sviluppo delle schede PCB successivi.
La verifica deve essere parte integrante del processo
Pianificazione ed esecuzione da sole non bastano: la progettazione richiede anche verifiche. Un agente IA potrebbe produrre un risultato apparentemente coerente ma allontanarsi involontariamente dai requisiti ricevuti all’inizio.
Più lunga e complessa diventa la catena del ragionamento, più è importante verificare gli esiti. Un flusso di lavoro agentico può quindi prevedere una fase di verifica separata nella quale il risultato viene valutato rispetto ai requisiti acquisiti all’inizio del processo.
L’architettura proposta fornisce tutte le funzioni richieste? I vincoli sono stati rispettati? Una supposizione fatta all’inizio non è più valida in seguito ad altre decisioni prese?
Laddove appropriato, il sistema può ripetere un’attività o segnalare il problema all’ingegnere invece di continuare a lavorare in silenzio.
Questa differenza è particolarmente importante nella fase attuale in cui l’IA si sta evolvendo da funzioni consultive a strumenti in grado di modificare i progetti. La fiducia nell’IA non può basarsi solo sulla fluidità con cui espone la sua risposta: deve nascere dalle informazioni tecniche rispetto alle quali la risposta può essere verificata.
Tenere gli ingegneri nel ciclo
Forse è inevitabile che una maggiore autonomia dell’IA porti alla domanda su quanto controllo gli ingegneri debbano cedere. La risposta ideale è: pochissimo.
L’automazione è da decenni un elemento importante della progettazione elettronica e ogni generazione di nuove tecnologie ha liberato gli ingegneri da compiti che in precedenza venivano svolti manualmente. L’IA agentica prosegue nella stessa direzione. Ma è cruciale capire che il suo valore sta nell’eliminare la fatica, non le responsabilità.
Spetta ancora all’ingegnere decidere che cosa costruire, valutare i compromessi architetturali e approvare le scelte di progettazione importanti. Un agente può analizzare alternative, eseguire fasi del flusso di lavoro e verificare il suo stesso lavoro, ma si deve fermare quando arriva a decisioni importanti e chiedere l’approvazione prima di procedere.
In questo modo la tecnologia diventa utile anche per l’esplorazione dei progetti. Se per generare un’architettura alternativa servono ore o giorni per attività manuali di ricerca dei componenti e ricostruzione, gli ingegneri sono costretti a limitare il ventaglio di opzioni analizzate.
Se questo lavoro può essere automatizzato in gran parte, si potranno valutare più alternative mantenendo la progettazione fluida e cambiando direzione con costi relativamente contenuti.
In definitiva, questo approccio potrebbe rivelarsi più efficace rispetto a semplicemente accorciare i tempi dello stesso processo di progettazione.
Un’architettura per gli agenti e per gli ingegneri
Il passaggio da assistenti IA ad agenti di ingegnerizzazione non avviene semplicemente associando modelli linguistici sempre più efficienti a strumenti di progettazione esistenti. Gli agenti hanno bisogno di informazioni strutturate su cui ragionare, compiti chiaramente definiti da eseguire, meccanismi per verificare quanto prodotto e limiti oltre i quali serve l’approvazione umana.
Dovranno inoltre avere la possibilità di operare su tutti i flussi di progettazione invece che in ambienti software isolati. Lo sviluppo di sistemi embedded comprende già requisiti, dati dei componenti, architettura, progettazione di schemi, simulazione, layout di PCB, approvvigionamenti e produzione. Un agente che opera in un ambiente chiuso crea semplicemente un passaggio aggiuntivo.
La prospettiva più interessante è quindi un ecosistema nel quale agenti specializzati e strumenti di progettazione possano lavorare insieme mentre il progettista mantiene il controllo dell’architettura complessiva.
L’IA migliorerà sicuramente le sue capacità. Ma, nella progettazione embedded, l’obiettivo non sono le capacità in sé: la prova vera è se l’IA può trasformare l’intento progettuale in azioni utili e verificabili. È questo il passaggio da un’IA che dice al progettista ciò che pensa a un agente che può aiutare il progettista a portare a termine il lavoro.
