RTM è un’azienda di IA industriale con sede a Seoul. La sua divisione vision sviluppa sistemi di monitoraggio della sicurezza basati sull’IA per gli stabilimenti di produzione: le telecamere già installate nello stabilimento sono monitorate 24 ore su 24 dai modelli Ultralytics YOLO26, che rilevano persone, cadute, intrusioni nelle zone pericolose e incendi o fumo, funzionando sui PC già disponibili presso il cliente, dalla grafica integrata fino a una GPU dedicata.
Monitorare telecamere che nessuno sorveglia#
Gli incidenti industriali tendono a verificarsi nei punti che nessuno sta sorvegliando. Le fabbriche hanno già telecamere su ogni linea, ma nessuno può guardare ogni flusso video in ogni momento. RTM ha creato un sistema per farlo ininterrottamente: ogni canale della telecamera esegue due modelli Ultralytics YOLO26, uno addestrato per rilevare le persone e l’altro gli incendi e il fumo, che alimentano un livello deterministico di gestione degli eventi, capace di generare allarmi in caso di cadute dei lavoratori e intrusioni nelle zone pericolose.
Negli ultimi sei mesi, la soluzione di IA per la sicurezza industriale di RTM è stata installata per funzionare 24/7 oppure è in fase di valutazione in loco presso 21 aziende manifatturiere dei settori dell’acciaio, delle batterie, della chimica e della plastica, alimentare e della robotica. Collegato ai sistemi CCTV esistenti, il sistema rileva quando un lavoratore entra in una zona pericolosa o cade e attiva avvisi tramite sistemi interni oppure, grazie all’integrazione PLC, controlla direttamente le apparecchiature collegate nello stabilimento.
Fig. 1. Feed live del rilevamento delle cadute RTM basato su Ultralytics YOLO (fonte dell'immagine: RTM).
Risolvere il problema dell’hardware che nessuno vuole acquistare#
Il monitoraggio della sicurezza deve competere con l’opzione di non installare nulla. Se un sistema richiede nuovo hardware server prima di poter monitorare anche una sola telecamera, spesso la valutazione si interrompe prima ancora di iniziare. Finora, i produttori hanno dovuto scegliere tra costoso hardware dedicato e nessun monitoraggio automatico.
RTM si è prefissata di eliminare questo compromesso: una sola installazione, eseguibile su qualsiasi PC già presente nella sala di controllo, dalla grafica integrata Intel fino a una NVIDIA RTX 3090, senza dover creare una configurazione diversa per ogni sede.
Per riuscirci, RTM esporta entrambi i modelli YOLO26 in formato ONNX con dimensioni statiche e li esegue tramite ONNX Runtime su cinque provider di esecuzione: TensorRT, CUDA, OpenVINO, DirectML e CPU. All’avvio, la libreria di inferenza rileva il produttore della GPU installata e seleziona automaticamente la catena di provider appropriata, così lo stesso file da 36 MB per modello funziona senza modifiche sia su una macchina priva di GPU dedicata sia su una scheda di fascia alta. L’applicazione distribuita non dipende da Python o PyTorch e non è necessario mantenere versioni diverse per ciascun produttore.
La head di rilevamento end-to-end di YOLO26 ha reso praticabile questo approccio basato su un singolo artefatto: poiché il modello restituisce direttamente i rilevamenti finali, il livello di inferenza C++ di RTM necessita solo di una soglia di confidenza e di una trasformazione inversa letterbox, senza dover reimplementare NMS né dover analizzare discrepanze di parità tra il percorso di addestramento Python e quello di distribuzione C++, una categoria di bug che si presenta in genere quando un rilevatore attraversa i confini tra linguaggi.
Quanto rende una GPU, dati alla mano#
RTM ha sottoposto a benchmark entrambi i modelli YOLO26-small (persona e fuoco/fumo) a due risoluzioni di input su una NVIDIA RTX 3090 (ONNX Runtime 1.26.0, provider di esecuzione CUDA, FP32, batch 1, solo passaggio forward). A 640×640, il modello per le persone impiega 4,20 ms per fotogramma e quello per fuoco/fumo 4,34 ms; a 1280×1280, entrambi salgono a circa 12,5 ms, mentre la memoria GPU passa da 406 MB a 1.302 MB. Ciò rende 640×640 circa 2,9 volte meno costoso per fotogramma e 3,2 volte più leggero in termini di memoria, mentre l'input più grande migliora il rilevamento degli oggetti piccoli e distanti. RTM distribuisce 640×640 come impostazione predefinita e mantiene disponibile l'esportazione 1280×1280 per i siti che dispongono di margine GPU da dedicare al margine di rilevamento anziché al numero di canali.
Il passaggio da CUDA a FP32 a TensorRT a FP16 ha ridotto il costo combinato per fotogramma dei due modelli da 8,68 ms a 6,26 ms, una riduzione del 28%, pari a circa 39,9 FPS su quattro canali con una singola GPU, invece di 28,8 FPS. Prima della distribuzione, RTM ha verificato che la conversione FP16 non compromettesse la precisione: il richiamo è rimasto invariato in ogni intervallo di dimensioni degli oggetti e a livello di evento, sia per il fuoco sia per il fumo. Nell'applicazione distribuita, una macchina con specifiche consigliate (Intel Core i7 di classe 16 core o superiore, 32 GB di RAM, RTX 5060 da 8 GB o superiore) supporta 6 canali simultanei, mentre una macchina di fascia bassa con sola grafica integrata ne supporta comunque 1, a fronte di un limite di prodotto di 10 canali per macchina.
Perché scegliere Ultralytics YOLO26?#
RTM addestra il rilevatore di persone e quello di fumo e incendi usando la stessa codebase di addestramento Ultralytics, e i due condividono 352 righe di codice senza alcuna diramazione specifica per dominio. Tra un rilevatore che cerca persone e uno che cerca incendi cambia solo un file di configurazione: dimensione dell'input, epoche, tasso di apprendimento e composizione del dataset. È una conseguenza diretta del modo in cui è stato realizzato Ultralytics YOLO. Un'unica architettura coerente e un'unica API di addestramento per le attività di rilevamento fanno sì che un nuovo ambito di rilevamento richieda una modifica alla configurazione, non una nuova pipeline: così un piccolo team di ingegneri ha potuto realizzare due modelli pronti per la produzione senza dover gestire due codebase.
La stessa coerenza ha reso poco rischioso anche il passaggio a YOLO26. RTM ha adottato YOLO26 quattro giorni dopo l’inizio del progetto, a maggio 2026, e la migrazione non ha richiesto di modificare neanche una riga del codice di training esistente: è bastato usare un checkpoint diverso. Poiché Ultralytics mantiene stabile l’interfaccia di training tra le diverse generazioni di modelli, passare all’architettura più recente non ha richiesto di riscrivere una pipeline che RTM aveva già realizzato e testato.
«Anche con lo stesso dataset, la dimensione dell'input e l'aumento dei dati cambiano le prestazioni del modello. Con Ultralytics tutto questo è gestito in un unico file di configurazione: modifichiamo alcuni valori, eseguiamo diverse varianti affiancate e scegliamo la migliore. Non tocchiamo mai il codice, quindi avviare dieci esecuzioni richiede più o meno lo stesso impegno di avviarne una.» — Ingegnere AI, RTM
Questa stabilità ha migliorato anche la precisione. Riunire un percorso di training sequenziale in cinque fasi in un’unica esecuzione congiunta ha portato la mAP50 di validazione da 0,672 a 0,689, mantenendo invariata la soglia operativa: un miglioramento che RTM ha ottenuto semplicemente ripetendo il training sulla stessa architettura YOLO26, senza riprogettare il modello. Inoltre, poiché YOLO26 si esporta senza problemi in un artefatto ONNX a dimensioni fisse e le soglie di rilevamento vengono distribuite in un file accessorio anziché essere compilate nell’applicazione, è stato possibile introdurre questo miglioramento di precisione negli impianti sostituendo un solo file ONNX, senza modificare l’applicazione host. Questo consente a un piccolo team di ingegneria di distribuire aggiornamenti del modello in ogni sede senza dover coordinare una release ed è una conseguenza diretta della scelta di YOLO26 anziché di un’architettura sviluppata su misura.
Cosa c’è a valle del rilevamento#
Gli allarmi di RTM non corrispondono ai rilevamenti grezzi: una persona nell’inquadratura non è un evento, ma lo è una persona caduta che rimane a terra. Sopra i due modelli YOLO26 si trova un livello deterministico di gestione degli eventi, che combina tracking, stato della postura, appartenenza alle zone e votazione su una finestra temporale scorrevole prima di attivare un allarme. Mantenere questa logica separata dal modello consente allo stesso rilevatore di persone di servire ogni sede, nonostante l’altezza e l’angolazione delle telecamere e le condizioni di illuminazione varino enormemente da uno stabilimento all’altro. Significa anche che i nuovi comportamenti di sicurezza possono riutilizzare i rilevamenti esistenti: RTM sta ora sviluppando il monitoraggio della conformità ai DPI usando lo stesso output del rilevamento delle persone, senza bisogno di nuovi modelli né di nuovo hardware nelle sedi dotate di GPU.
L’impatto complessivo#
L’impatto è particolarmente evidente presso i clienti di RTM che integrano robot collaborativi: forniscono e installano cobot negli stabilimenti, dove da tempo i lavoratori rischiano di urtare i robot nonostante le barriere fisiche o laser di sicurezza. Con il sistema di RTM, le intrusioni nelle zone pericolose vengono rilevate e attivano immediatamente l’arresto del robot collegato al PLC, senza ritardi; da allora, questi integratori lo hanno adottato come dispositivo di sicurezza predefinito, al posto delle barriere fisiche.
Un cliente del settore siderurgico ha dichiarato che la capacità di Ultralytics YOLO di adattare gli scenari di rilevamento alle diverse sedi gli ha permesso di ridurre di oltre 100 unità il personale addetto al monitoraggio della sicurezza che in precedenza pattugliava gli stabilimenti. Più in generale, i produttori descrivono la soluzione di RTM come la più facile da installare e la più conveniente tra le opzioni di monitoraggio della sicurezza valutate; il rilevamento di zone pericolose, cadute e incendi/fumo copre le loro esigenze principali.
Ampliare le funzionalità con gli stessi modelli#
Il prossimo passo di RTM è il rilevamento della conformità ai DPI, basato interamente sull’output esistente del rilevamento delle persone. Non occorre addestrare un nuovo modello e, nelle sedi con capacità GPU disponibile, non serve installare nuovo hardware. Man mano che l’implementazione prosegue in altri stabilimenti e su ulteriori fasce di hardware, la stessa singola esportazione ONNX per modello continua a gestire il carico, dal PC con grafica integrata dalle specifiche più basse fino al server GPU più potente dello stabilimento.
Ti interessa creare soluzioni di IA per la visione? Esplora i nostri modelli Ultralytics YOLO, scopri come vengono usati nei diversi settori, inclusa la computer vision nel settore manifatturiero, e consulta le opzioni di licenza per iniziare.
Scritto da
Digital Content Manager · Ultralytics
