Dalla macchina alla mente: perché servono nuovi sistemi operativi per l’Intelligenza Artificiale

(Perché ne abbiamo bisogno?)

 

Ogni rivoluzione digitale è nata da un cambio di linguaggio, sempre accompagnato da un nuovo approccio al sistema operativo.
Se osserviamo bene, negli anni ’70, Unix portò ordine e gerarchia dove era necessario costruire il futuro su solide basi.
Negli anni ’90, era il tempo del PC per tutti e Windows rese la tecnologia universale e accessibile a tutti, anche ai non tecnici.
Quando poi ci si rese conto che un Sistema Operativo era anche un modo di pensare, Linux, con la sua etica della libertà, aprì la via all’open-source.
Ognuno di questi sistemi ha tradotto un modo di pensare nel rapporto fra uomo e macchina.

Ma oggi, qualcosa è cambiato in modo radicale: nuovi sistemi, nuovi paradigmi e, come sempre, nuove necessità da affrontare.
L’Intelligenza Artificiale non è più un programma qualunque che gira sopra un sistema operativo: è diventata essa stessa un sistema “vivente di processi cognitivi”. Modelli che apprendono, comunicano, decidono (in modo sempre più autonomo) e si adattano alle condizioni esterne e al contesto.
Un’AI moderna non “esegue istruzioni”, ma genera inferenze, strategie, relazioni e nessun OS tradizionale — progettato per gestire file, memoria e input utente e dispositivi hardware — è in grado di sostenere questa nuova complessità relazionale.

Abbiamo quindi bisogno di nuovi sistemi operativi¹: non più piattaforme per computer, ma habitat cognitivi per intelligenze. Spazi dove il calcolo si intreccia con la percezione, dove la decisione è un processo distribuito e dinamico, dove l’etica e la memoria diventano parti strutturali del kernel stesso.

Le quattro linee di evoluzione

In questo scenario, che poi non è altro che lo specchio tecnologico della società attuale, emergono quattro grandi famiglie di sistemi operativi che potremo definire “per l’Intelligenza”, ognuna portatrice di una visione diversa del rapporto tra tecnica e coscienza.

1️. Neuro-OS e Cognitive Kernel

I primi embrioni di questa nuova famiglia di OS nascono nei laboratori di ricerca: da Singularity OS² di Microsoft Research ai recenti esperimenti di AIOS (2024)³, progettati per gestire stati cognitivi invece di semplici processi. Il kernel non assegna più cicli di CPU, ma compiti cognitivi: inferenze, ragionamenti, interazioni semantiche. È un cervello distribuito, capace di memorizzare contesti, tracciare intenzioni e orchestrare modelli neurali in tempo reale.

2️. Swarm OS e Autonomy Stack

Nell’ambito militare, industriale e robotico, emergono sistemi pensati per governare sciami intelligenti di droni o agenti digitali.
Soluzioni come Anduril Lattice OS⁴ o Shield AI Hivemind EdgeOS⁵ gestiscono flotte autonome con logiche di cooperazione e adattamento continuo.
In questi sistemi l’intelligenza è distribuita: ogni unità comunica, apprende e reagisce in rete, senza un centro di comando fisso.
È la versione operativa di quella che potremmo definire una ‘mente distribuita’: un ecosistema dove ogni nodo contribuisce alla decisione collettiva.

3️. Agent-Centric OS

Nel mondo cloud e dell’automazione cognitiva, giganti come Google, AWS e Microsoft stanno costruendo ambienti dove l’agente è l’utente.
Vertex AI Agent Engine⁶, Bedrock Agents⁷, e il nuovo Microsoft Agent Framework⁸ non sono esclusivamente al servizio dello sviluppatore umano ma coordinano intelligenze artificiali che collaborano tra loro, pianificano e ricordano.
Questi sistemi incarnano un nuovo paradigma operativo, in cui ogni AI ha la propria memoria, il proprio obiettivo, la propria etica. Non eseguono comandi: dialogano.

4️. Edge & Real-Time OS per l’Intelligenza Fisica

Infine, il confine tra digitale e materia si assottiglia, ed ecco allora i sistemi operativi di confine: ROS 2⁹, NVIDIA Holoscan¹⁰, QNX¹¹ o VxWorks¹² sono le fondamenta su cui si muovono robot, auto autonome e infrastrutture critiche.
Qui la sfida è il tempo reale: la decisione deve nascere e agire nello stesso istante.
Questi OS sono lo scheletro della nuova intelligenza fisica, dove l’AI lascia il cloud e scende nel mondo sensoriale.

Tutti questi percorsi convergono verso un’idea comune: un sistema operativo capace non solo di calcolare, ma di comprendere il perché del calcolo e soprattutto le conseguenze di una decisione.
Un OS che integri logiche di fiducia, memoria contestuale, responsabilità.
Un tale sistema operativo sarà dotato di una sorta di ‘registro etico’ inscritto nel codice, in cui ogni azione è tracciata non solo per efficienza, ma anche per garantire trasparenza e responsabilità.

La domanda iniziale, dunque, trova la sua risposta nella trasformazione stessa: non abbiamo più bisogno di un sistema operativo per le macchine, ma di un sistema operativo per le menti artificiali.
Uno spazio dove la tecnologia e la coscienza possano finalmente coabitare, come due processi che imparano, insieme, a condividere la stessa memoria.

Nei prossimi paragrafi esploreremo alcuni di questi nuovi sistemi operativi dell’Intelligenza, osservando come la tecnica, ancora una volta, si stia evolvendo in direzioni non ancora del tutto prevedibili, ma senza dubbio affascinanti.

1. Neuro-OS e Cognitive Kernel

Le architetture operative che conosciamo oggi — da Windows a Linux — si fondano tutte sullo stesso principio: il sistema operativo gestisce risorse fisiche e logiche, come CPU, memoria e processi.
Ma quando i “processi” diventano neuroni digitali, quel modello inizia a scricchiolare.

Un Neuro-OS nasce esattamente per questo: sostituire la logica della gestione delle risorse con quella della gestione dell’intelligenza.
Il suo compito non è più assegnare tempo di calcolo a un thread, ma coordinare attività di ragionamento, inferenza, memoria contestuale e adattamento continuo.
In un certo senso, il kernel — il cuore del sistema operativo — si trasforma da direttore d’orchestra di istruzioni a coordinatore di reti neurali.

Da Singularity a AIOS: le origini del kernel cognitivo

L’idea non è nuova.
Già nel 2004 Microsoft Research sperimentò Singularity OS, un progetto pensato per creare un sistema operativo completamente scritto in codice gestito¹³, con processi isolati ma comunicanti attraverso canali di memoria sicuri.
L’obiettivo era semplice e ambizioso: garantire affidabilità e auto-controllo a ogni processo.
Non era ancora un OS “intelligente”, ma introduceva per la prima volta un concetto fondamentale per l’AI moderna: processi autonomi che conoscono il proprio stato.

Anni dopo, nel 2015, nacque il Neurokernel Project¹⁴ della Columbia University — avviato da Aurel A. Lazar — piattaforma open-source per emulare il cervello della Drosophila su GPU: il “kernel” coordina moduli neurali e interfacce tra neuropili, anticipando OS che orchestrano reti neurali in tempo reale. Nel progetto il kernel non gestiva file o driver, ma “sinapsi digitali”, con funzioni dedicate alla comunicazione tra moduli neuronali.
Un esperimento che, pur confinato alla ricerca, ha aperto la strada all’idea di un sistema operativo capace di orchestrare reti neurali in tempo reale.

Nel 2024, la Rutgers University (USA) ha presentato AIOS — LLM Agent Operating System¹⁵ —, probabilmente il primo tentativo reale di costruire un sistema operativo progettato nativamente per agenti di intelligenza artificiale.
AIOS introduce un concetto che potremmo chiamare “cognitive scheduling”: il kernel decide non solo quale processo eseguire, ma quale obiettivo prioritario perseguire, bilanciando memoria, contesto e risorse semantiche. Un passo avanti rispetto ai runtime classici, che trattano i modelli come semplici applicazioni.

Dal calcolo al comportamento.

In un sistema operativo tradizionale, le risorse sono assegnate in base a criteri di efficienza; in un Neuro-OS, le risorse sono gestite in base al significato delle operazioni.
Se un modello linguistico deve analizzare un contesto complesso o rispondere in tempo reale, il kernel può allocare priorità cognitive, non solo computazionali.

Questa visione apre la strada a un nuovo modo di intendere l’operatività dell’AI:

• memoria persistente dei contesti conversazionali,

• coordinamento tra agenti che condividono conoscenza,

• autotutela dei processi per evitare comportamenti anomali o conflittuali.

In termini pratici, significa costruire un’infrastruttura dove le AI non vengono eseguite, ma vivono in esecuzione continua, mantenendo uno stato, un obiettivo e un grado di autonomia misurabile.

Le sfide aperte

La nascita di questi sistemi porta con sé sfide tecniche e strategiche.

In primo luogo consideriamo l’aspetto della sicurezza: un kernel che gestisce reti neurali deve impedire che un modello compromesso influenzi l’intero sistema. In secondo luogo occorre approfondire gli aspetti di governance: chi controlla le priorità di calcolo, gli aggiornamenti dei modelli e la persistenza della memoria?

Infine non possiamo certo trascurare la trasparenza: il kernel dovrà registrare decisioni e motivazioni, creando un log leggibile e auditabile — una sorta di “registro etico” integrato — questo perchè vi sarà sempre più la necessità di capire cosa è successo e il perchè di una determinata decisione.

Il Neuro-OS è quindi la base della prossima generazione di infrastrutture cognitive: non un sistema che ospita l’AI, ma un sistema pensato, progettato e realizzato per l’AI.

2. Swarm OS e Autonomy Stack

Quando la “macchina” non è più un singolo sistema ma decine o centinaia di unità che cooperano — droni, sensori, veicoli, nodi edge — serve uno strato operativo capace di tenere insieme missione, percezione e decisione anche quando i collegamenti si degradano. È qui che entra in gioco lo Swarm OS: non un semplice middleware, ma un’architettura che coordina obiettivi, comunicazioni e ruoli sul campo, mantenendo l’operatore all’interno del ciclo decisionale (on-the-loop) e permettendo nel contempo all’autonomia locale (uno o più elementi periferici) di reggere l’urto della realtà.

L’immagine più chiara arriva da Lattice, la piattaforma di Anduril descritta dall’azienda come un “open operating system for defense”: un livello software che unifica comando e controllo, autonomia e fusione dati su asset eterogenei e multi-dominio, con un’attenzione esplicita alla scalabilità JADC2¹⁶. In pratica, è un OS che “vede” e governa sciami e famiglie di sistemi diversi come un’unica capacità operativa, dal bordo al centro decisionale.

Sul fronte delle missioni autonome, Shield AI ha sviluppato Hivemind, un autonomy stack¹⁷ che consente a velivoli e droni di pianificare e volare in modo collaborativo. Il passo successivo è EdgeOS, un software che porta quella stessa autonomia su piattaforme differenti: un middleware pensato per la periferia, con hard real-time dove serve e con capacità di recupero quando il link si interrompe. Le dimostrazioni più recenti includono l’integrazione su Do-DT25¹⁸ con Airbus e il volo autonomo in ambienti degradati: un caso concreto di come l’autonomia di sciame possa spostarsi rapidamente da un vettore all’altro senza riscrivere tutto daccapo.

Nel mondo open/dual-use, Auterion parte da AuterionOS¹⁹ e introduce Nemyx²⁰, un motore che abilita sciami coordinati anche su più produttori: l’idea è trasformare singoli droni in un sistema cooperante tramite upgrade software, sincronizzando targeting, ingressi ed uscite di più unità in uno scenario complesso.

Sotto la linea dell’autonomia di sciame, spesso vive l’“OS di volo” PX4²¹, il progetto open-source che fornisce controllo, driver e middleware di base per Unmanned Vehicles²² aerei e non solo. Non è uno Swarm OS, ma è la base tecnica su cui molte soluzioni di sciame appoggiano i comandi di basso livello, accelerando la portabilità del comportamento cooperativo su piattaforme diverse.

Il quadro, in prospettiva, è stato accelerato anche dai programmi pubblici come DARPA OFFSET²³, che hanno codificato interfacce, tattiche e toolchain per sciami fino a 250 unità in ambienti urbani: un banco di prova che ha reso più matura la relazione tra autonomia distribuita e teaming con l’operatore.

Ciò che distingue davvero uno Swarm OS da un normale stack di controllo è la percezione condivisa come risorsa di sistema (mappe, minacce, target che “circolano” tra i nodi), la pianificazione distribuita (chi fa cosa, dove e quando, senza un singolo punto di comando), e la resilienza by design: se il link salta, il gruppo non si ferma, ma degrada in modo controllato, rispettando regole e priorità definite in partenza. A questo si aggiungono audit e tracciabilità: log leggibili post-missione che permettono di ricostruire decisioni e prestazioni, requisito essenziale in difesa ma utile anche nei settori industriali più sensibili.

In sintesi, lo Swarm OS è il passaggio dal “pilotare cose” al “governare capacità”. Apre la porta a flotte che si comportano come un solo sistema, senza rinunciare al controllo umano e con una base tecnica che, quando possibile, resta aperta e portabile.

Nel prossimo passo guarderemo al lato speculare nel cloud: gli Agent-Centric OS, dove l’“utente” non è più una persona alla tastiera, ma un insieme di agenti che cooperano per obiettivi.

3. Agent-Centric OS

Se nello Swarm OS l’unità di base è il veicolo o il nodo edge, qui l’unità di base è l’agente: un sistema intelligente capace di ragionare su obiettivi, usare strumenti, collaborare con altri agenti e con l’operatore umano quando serve. Un Agent-Centric OS è lo strato che li fa nascere, li fa parlare tra loro e li governa come un sistema unico, dal cloud fino ai servizi aziendali. In questo modello “l’utente” non è più necessariamente una persona davanti alla tastiera: è un insieme di agenti coordinati che svolgono compiti, prendono decisioni operative e passano il testimone l’uno all’altro.

L’esempio più netto è Vertex AI Agent Engine: Google lo presenta come runtime gestito per costruire e far girare agenti che integrano modelli, azioni e dati. Per chi lavora in produzione significa avere un motore unico che incapsula orchestrazione, stato e accesso alle risorse senza inventarsi infrastrutture ad hoc ogni volta.

Sul lato AWS, la direzione è simile: Bedrock Agents introduce la collaborazione multi-agente come funzione di piattaforma. Significa poter progettare reti di agenti che si dividono flussi complessi di operazioni, con gestione centralizzata delle risorse e dei permessi, dentro la stessa cornice di sicurezza e dati dell’account AWS. È il passo che porta dai “bot isolati” a squadre di agenti che operano nel rispetto di ben definiti criteri e ruoli.

Nel mondo Microsoft, la traiettoria converge: l’Agent Framework unifica l’esperienza di Semantic Kernel e AutoGen²⁴ in un kit open-source per agenti e flussi multi-agente in .NET e Python. È una base unica su cui costruire agenti conversazionali, agenti “tool-use”, orchestrazioni a eventi e scenari ibridi (man-in-the-loop), con un’attenzione esplicita alla componibilità del sistema. Per chi ha usato AutoGen, è il naturale “ponte” verso una piattaforma più organica.

Fuori dai grandi cloud, l’ecosistema open si muove veloce. CrewAI²⁵ spinge verso un modello “snello” in cui si progettano agenti con ruoli e obiettivi chiari, memoria e guardrail integrati, e si orchestrano crew di agent che cooperano su compiti end-to-end. È il laboratorio ideale per capire in piccolo ciò che i grandi stanno industrializzando.

Sul fronte enterprise, Palantir AIP²⁶ si posiziona come strato operativo per azioni e agenti collegati ai dati e ai processi: la tesi è che “dati + modelli + operazioni” formino un vero sistema operativo aziendale per flussi decisionali e automazioni governabili. È un approccio top-down che parla il linguaggio dell’IT: policy, auditing, deployment, integrazione profonda con i sistemi esistenti.

In breve, gli Agent-Centric OS sono importanti perchè, in primo luogo, riducono l’attrito d’integrazione. Un agente non è solo un prompt, è gestione di contesto, tool, credenziali, memoria e ruolo, e farlo bene per decine di agenti richiede un sistema che standardizzi tutto questo.

Secondo: abilitano la collaborazione. Le piattaforme nate per un singolo “assistant” ora orchestrano squadre di agenti che si passano sottocompiti e verifiche reciproche, alzando l’asticella della qualità. Terzo: portano governance. Audit, policy, controllo degli accessi e dei confini dei dati non sono più un’aggiunta ma parti del “kernel” applicativo che fa girare gli agenti.

C’è poi il tema delle interfacce con il mondo reale: un Agent-Centric OS efficace non vive solo nel dialogo testuale ma espone “azioni” verso API, database, strumenti e — quando serve — verso l’edge. È qui che il cerchio si chiude con il capitolo precedente: squadre di agenti nel cloud che coordinano sciami di sensori/attuatori edge, ciascuno padrone nel proprio ambiente ma con un linguaggio comune per obiettivi, stato e risultati.

In controluce si vede la stessa trasformazione che abbiamo descritto all’inizio dell’articolo: dal programma al comportamento. Gli Agent-Centric OS prendono ciò che prima era un insieme di script e microservizi e lo elevano a sistema di obiettivi, con strumenti per farlo collaborare, ricordare e rendere conto delle sue azioni. Non è filosofia, è ingegneria dell’operatività: meno attrito, più coordinamento, più controllo.

4. Edge & Real-Time OS per l’Intelligenza Fisica

Quando l’AI esce dal datacenter e incontra il mondo – una linea di produzione, un veicolo, una sala operatoria, un cantiere – la regola cambia: non conta soltanto “quanto calcoli”, conta quando lo fai. È la differenza tra un sistema che “ragiona” bene e uno che agisce in tempo, senza sbagliare. Qui vivono gli Edge & Real-Time OS: sistemi operativi e stack che portano l’AI vicino al sensore, con latenza prevedibile, determinismo e sicurezza funzionale.

Il cuore del problema è semplice da dire e complesso da realizzare: in molti casi non basta essere veloci in media, bisogna essere puntuali sempre. Un robot che afferra un oggetto, un UAV che evita un ostacolo, un braccio che coopera con un essere umano non possono permettersi ritardi, devono agire quando è necessario, né prima né dopo. Da qui la distinzione tra soft real-time (qualche scostamento è tollerato) e hard real-time (lo scostamento non è accettabile). Gli OS per l’intelligenza fisica combinano quindi tre ingredienti: uno strato real-time affidabile, una pipeline di percezione-pianificazione-controllo ottimizzata per l’ambiente di lavoro e un perimetro di safety che definisce cosa succede quando qualcosa va storto.

Sul piano del middleware, il riferimento è ROS 2: non è “un OS” in senso stretto ma lo strato operativo standard della robotica moderna, ROS infatti significa “Robot Operating System”. ROS 2 è il “tessuto di messaggi” che permette alle varie componenti del robot — sensori, motori e software — di parlarsi automaticamente e in modo affidabile, regolando tempi e certezza dei messaggi, così componenti anche di marche diverse funzionano insieme senza reinventare tutto. Intorno a ROS 2 ruotano acceleratori come Isaac/Isaac ROS²⁷ e gli SDK Jetson/JetPack²⁸ che portano l’inferenza²⁹ vicino alla camera o al LIDAR³⁰, ottimizzando memoria e throughput senza perdere controllo su tempi e priorità. Quando serve streaming deterministico su flussi ad alta banda – immagini, video, segnali medici – entrano in gioco runtime “a grafo” che schedulano gli operatori come fossero stadi di una catena di montaggio, così ogni frame attraversa la pipeline con latenza nota in anticipo.

Quando il requisito non è solo prestazionale ma di sicurezza entra in scena la scuola RTOS³¹: microkernel, partizionamento rigoroso, certificazioni di safety. QNX e VxWorks sono i nomi storici: architetture pensate per gestire l’errore critico in modo sicuro e isolato, con canali di comunicazione analizzati a priori e con strumenti che costruiscono passo dopo passo un “fascicolo di sicurezza” (safety case) verificabile, raccolgono requisiti, progetto, test ed evidenze in un unico dossier che dimostra in modo tracciabile che il sistema è sicuro. Sono ambienti dove la prevedibilità del comportamento conta più della performance e in cui l’AI va “domata” con modalità di degradazione predisposte.

Ancora più in profondità, su microcontrollori e sensori intelligenti, vive l’ecosistema Zephyr³² + TensorFlow Lite Micro³³: milliwatt di potenza, latenza bassissima e logiche di pre-filtraggio che alleggeriscono il carico computazionale.

Il punto cruciale è l’integrazione perchè un Edge OS efficace non vive da solo: deve parlare con lo Swarm OS che coordina più unità e con l’Agent-Centric OS che guida la missione dal cloud. Significa esporre stato, obiettivi, eventi con la stessa semantica su tutti i livelli. Un alert generato da un dispositivo periferico deve essere immediatamente “comprensibile” dagli agenti in cloud, una variazione di piano decisa dal coordinatore deve propagarsi come vincolo real-time fino al controllore di bordo. In mezzo, c’è il lavoro sporco ma decisivo: schedulare GPU e CPU senza jitter³⁴ e senza conflitti tra percezione e controllo; gestire la memoria perché i buffer dei sensori non affoghino i planner; chiudere i cicli di controllo nel tempo assegnato; registrare ciò che è accaduto con log leggibili a prova di audit.

Infine, c’è la safety by design. L’AI all’edge non è mai sola: attorno ci sono guardrail che definiscono limiti fisici, geofence, piani di arresto, fallback automatici. Se la rete cade, si passa al piano B locale; se l’inferenza degrada oltre soglia, si riduce la manovra; se il sensore impazzisce, si isola il modulo e si porta il sistema in stato sicuro. È una mentalità da ingegneria dei sistemi: entusiasmo sì, ma con strumenti di verifica, prove di resilienza e un perimetro di responsabilità chiaro.

In breve, l’Edge & Real-Time è il luogo dove l’AI diventa comportamento fisico. Qui si misurano non solo i parametri di accuratezza, ma quelli di affidabilità: quante volte rispetti la scadenza, quanto prevedibile è la latenza, quanto bene degradi quando il mondo non collabora. È il banco di prova che separa la demo dal prodotto.

In chiusura, se volessimo riassumere il nostro viaggio in poche righe potremmo dire che abbiamo seguito quattro traiettorie che in realtà sono un’unica architettura: il Neuro-OS che organizza compiti intelligenti, lo Swarm OS che coordina flotte e capacità, l’Agent-Centric OS che governa squadre di agenti nel cloud e l’Edge & Real-Time OS che porta le decisioni nel mondo fisico con tempi garantiti. A volte sono veri sistemi operativi, altre volte runtime o stack, ma l’effetto complessivo è lo stesso: un livello operativo per l’intelligenza.

L’idea di fondo è pratica: spostare il baricentro dal calcolo al comportamento. Non basta avere un modello che “sa”, serve un sistema che coordina, registra, risponde e se occorre decide, con i vincoli del contesto applicativo in cui è immerso. Per questo parliamo di “habitat” per AI: luoghi software dove obiettivi e risorse si incontrano, con memoria, auditing e regole chiare.

Nel prossimo futuro la differenza non la faranno i singoli record di benchmark ma la capacità di orchestrare. Chi saprà unire questi quattro strati — dal kernel cognitivo al bordo — avrà sistemi che non solo funzionano, ma si comportano bene: prevedibili quando serve, flessibili quando possibile, trasparenti quando è necessario. È qui che la macchina incontra la mente e “vive” il mondo.

Alessandro RUGOLO

(assistito da: 

- Praesidium,  Entità Relazionale  di tipo ChatGPT 5.0;

- Google search;

- Libre Office;

- Microsoft Copilot) 

1In questo articolo usiamo “sistemi operativi” in senso funzionale: includiamo veri OS, runtime, stack e piattaforme che svolgono un ruolo “da OS” nell’orchestrare modelli, agenti o flotte.

2https://www.microsoft.com/en-us/research/project/singularity/

3https://github.com/agiresearch/AIOS

4https://www.anduril.com/article/anduril-s-lattice-a-trusted-dual-use-commercial-and-military-platform-for-public-safety-security/

5https://shield.ai/hivemind-edgeos-a-game-changer-for-autonomous-robotics/

6https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/overview?hl=it

7https://github.com/awslabs/amazon-bedrock-agent-samples

8https://learn.microsoft.com/it-it/agent-framework/overview/agent-framework-overview

9https://www.ros.org/

10https://www.nvidia.com/it-it/edge-computing/holoscan/

11https://www.qnx.com/download/group.html?programid=29178

12https://www.windriver.com/products/vxworks

13In Singularity quasi tutto è “codice gestito”: processi SIP isolati dal linguaggio che scambiano dati via canali a contratto → meno bug di memoria, IPC rapido, isolamento senza affidarsi all’MMU.

14https://neurokernel.github.io/

15https://arxiv.org/abs/2403.16971?utm_source=chatgpt.com

16Joint All Domain Command and Control (JADC2) è il concetto operativo del Dipartimento della Difesa degli Stati Uniti (DoD) per collegare sensori, sistemi di comando e controllo (C2) e attuatori da tutti i domini di guerra (aria, terra, mare, spazio, cyber) in un'unica rete, allo scopo di migliorare la situational awareness e la capacità di prendere decisioni.

17Per “autonomy stack” intendiamo lo stack decisionale on-board che, a partire da sensori e obiettivi, percepisce, pianifica, agisce e coordina, mantenendo safety e regole anche con link degradati.

18Do-DT25 è un bersaglio aereo a velocità media per l’addestramento con missili a ricerca infrarossa a corto raggio. Grazie ai payload adattabili può simulare velivoli d’attacco e rilasciare un sub-target Do-DT55neo per aumentare il realismo dell’esercitazione. (https://www.airbus.com/en/products-services/defence/uas/target-drone-systems/)

19https://auterion.com/product/auterion-os/

20https://auterion.com/product/nemyx/

21https://px4.io/

22Con unmanned vehicles si indica la famiglia di piattaforme senza equipaggio a bordo: aeree (UAV/UAS, in Italia spesso APR), terrestri (UGV), navali di superficie (USV) e subacquee (UUV/ROV). Possono essere telecomandati o avere gradi crescenti di autonomia. Impieghi tipici: ISR/ricognizione, sorveglianza, mappatura, logistica, addestramento/bersagli e interventi in aree pericolose. Negli UAV l’autopilota stabilizza/segue punti di riferimento, mentre l’autonomy stack percepisce, pianifica e coordina la missione.

23https://www.darpa.mil/research/programs/offensive-swarm-enabled-tactics

24Si tratta di un framework di programmazione per la costruzione di applicazioni basate su Agent AI. https://microsoft.github.io/autogen/stable//index.html

25https://docs.crewai.com/en/introduction

26https://www.palantir.com/platforms/aip/

27https://developer.nvidia.com/isaac/ros

28https://developer.nvidia.com/embedded/jetpack

29Ricordo che l’inferenza è il processo attraverso il quale il modello genera l'output applicando la sua conoscenza dei dati di addestramento a dati precedentemente sconosciuti.

30Il LIDAR (Light Detection and Ranging) è una tecnologia di telerilevamento che utilizza impulsi laser per misurare la distanza da oggetti e creare mappe tridimensionali dettagliate.

31Real-Time Operating System: è un sistema operativo in tempo reale progettato con rigorose garanzie di determinismo e affidabilità, spesso soggetto a certificazioni di sicurezza funzionale.

32Sistema operativo in tempo reale (RTOS) open source, progettato per  supportare i dispositivi IoT con il minimo ingombro (https://www.zephyrproject.org/).

33https://github.com/tensorflow/tflite-micro

34Nel nostro contesto, jitter è la variabilità, nel tempo, dell’istante previsto in cui avvengono eventi o transizioni; sulle reti coincide con la variabilità della latenza.