Test del Rumore al Passaggio con Elaborazione Dati Automatizzata a Bordo Veicolo

Leane International ha sviluppato un sistema flessibile di misura del rumore al passaggio (PBN) che integra l'automazione DewesoftX con l'analisi basata su Python tramite l'ambiente GarageLab. La soluzione consente a un singolo operatore a bordo del veicolo di gestire l'intero flusso di lavoro di test, dall'acquisizione dei dati alla convalida automatizzata delle funzioni e alla reportistica finale. Combinando l'elaborazione in tempo reale, un'interfaccia grafica intuitiva e l'analisi automatizzata a lotti, il sistema offre un'alternativa economica e altamente adattabile alle tradizionali soluzioni di test PBN.

Introduzione

La soluzione chiavi in ​​mano di Leane per la misura e l'analisi del rumore di passaggio si basa su Dewesoft Sequencer, DewesoftX e Leane GarageLab. Il sistema offre un flusso di lavoro completamente automatizzato, dall'avvio della sessione di test fino alla generazione di un report finale personalizzato, senza mai uscire dall'ambiente Dewesoft.

Il setup di misura include una semplice interfaccia grafica basata su widget di controllo degli input, che consente un facile accesso alle funzioni principali. Allo stesso tempo, il Sequencer avvia automaticamente script Python basati su GarageLab per fornire risultati immediati dopo ogni test e, al termine della sessione, per generare un report di post-elaborazione e un set completo di file di dati.

I test PBN sono obbligatori per ottenere l'omologazione degli pneumatici e l'omologazione del veicolo. Sebbene i protocolli di test differiscano per alcuni dettagli rilevanti, tutti richiedono una precisa sincronizzazione delle misure di velocità e posizione del veicolo con la misura del rumore, elaborando diverse sessioni di test e la sovrapposizione dei risultati provenienti da un batch di file di dati.

Sebbene il processo di misura possa essere eseguito efficacemente con Dewesoft, abbiamo dovuto gestire l'analisi batch e la reportistica in modo diverso. Abbiamo scelto di combinare le funzionalità di automazione del Dewesoft Sequencer con la facilità d'uso del linguaggio di automazione più diffuso, ovvero Python, attraverso il nostro ambiente di sviluppo proprietario, GarageLab.

La soluzione risultante consente all'utente di gestire l'intera procedura di test direttamente dal veicolo, di far eseguire automaticamente uno script di elaborazione dal sequenziatore Dewesoft per valutare la validità di ogni singola prova e di eseguire l'analisi batch di tutte le prove al termine della sessione di misura, senza uscire da Dewesoft. In alternativa, è possibile eseguire lo stesso strumento di analisi per la post-elaborazione in qualsiasi momento.

Contesto di applicazione

Un importante produttore domina il mercato delle apparecchiature di strumentazione per i test di rumorosità in transito, vantando una solida reputazione per la qualità e la precisione delle proprie apparecchiature e offrendo una soluzione completa e specifica per questo tipo di test.

Le misure del rumore vengono effettuate più volte durante il ciclo di sviluppo degli pneumatici per il benchmarking, la validazione dei modelli di simulazione, la valutazione delle prestazioni di alcuni modelli di prodotto selezionati e, infine, l'omologazione del nuovo prodotto. In ogni fase, gli utenti devono sostituire diversi set di pneumatici con specifiche differenti su un veicolo "di riferimento" specifico per effettuare i test in condizioni comparabili.

Il quadro normativo è ben consolidato e comprende le seguenti norme:

• UNECE 117: Emissioni sonore degli pneumatici

• UNECE 51: Emissioni sonore dei veicoli a motore (tipo M e N)

• UNECE 40: Emissioni sonore dei motocicli

Queste normative prevedono diversi metodi di prova, diverse procedure di prova (in folle o in accelerazione), diversi canali di misura e diverse procedure di elaborazione.

Inoltre, come accade di consueto in ogni settore, a volte i produttori di apparecchiature originali desiderano estendere e modificare le procedure prescritte dalla normativa per ottenere maggiori informazioni sul comportamento dei loro pneumatici/veicoli in un intervallo operativo più ampio.

La soluzione che presentiamo si rivolge a un'applicazione specifica, ovvero la norma R117, ma la sua progettazione la rende facilmente adattabile ad altri protocolli di prova.

Il cliente: un importante produttore di pneumatici, tra i leader nel settore dei veicoli commerciali pesanti. Dewesoft è il nostro principale partner e fornitore di sistemi di acquisizione dati (DAQ) di fascia alta, mentre noi, Leane International, agiamo come integratori di sistema e fornitori finali della soluzione chiavi in ​​mano..

Problematica del cliente

Il cliente si è rivolto a noi richiedendo un nuovo sistema di prova per il rumore di rotolamento degli pneumatici, ma ha anche chiesto costi inferiori e una maggiore flessibilità rispetto alla soluzione del leader di mercato. Gli altri requisiti chiave erano:

• Correlare il livello di rumore con la posizione del veicolo sull'intera area di misura (non solo il livello massimo).

• Un operatore a bordo del veicolo che controllasse l'intera procedura di test.

• Eseguire test in diverse postazioni e senza la necessità di RTK.

• Memorizzare il rumore di fondo prima di ogni ciclo di test nel file di test.

• Eseguire i test in entrambe le direzioni di marcia, avanti e indietro, per ridurre i tempi di prova.

• Elaborazione automatica di ogni ciclo di test e possibilità di conservare o eliminare il file di dati.

• Elaborazione di un batch di file selezionati, inclusi best fit e normalizzazione secondo la norma UNECE R117.

Analisi

Considerati il ​​regolamento e i requisiti aggiuntivi, è stato chiaro fin da subito che dovevamo trovare una soluzione alle seguenti sfide principali.

Precisione e sincronizzazione della posizione rispetto alla posizione del microfono senza RTK

Per l'analisi dei dati, è necessario determinare il livello di rumore tra i microfoni, ovvero al punto PP (vedi figura).

La connessione Wi-Fi e l'orologio a tempo assoluto GNSS consentono la sincronizzazione delle misurazioni del microfono e dei dati della stazione meteorologica raccolti a terra con la posizione GNSS e altri dati del veicolo raccolti a bordo.

Il problema risiede nella scarsa precisione dei dati di posizione GNSS senza RTK. Quando il GNSS restituisce la posizione di un veicolo sulla linea PP, il veicolo potrebbe trovarsi a pochi metri da quella posizione, ma non possiamo conoscerne la posizione esatta.

Gestione dell'automazione dei test a bordo del veicolo

La gestione a bordo veicolo è una funzionalità chiave per i clienti che desiderano aumentare l'efficienza dei test. Durante le sessioni di test di sviluppo, il collaudatore può eseguire le misure in autonomia. Il sequenziatore Dewesoft sembrava lo strumento ideale, tuttavia avremmo dovuto sviluppare un'interfaccia utente intuitiva per semplificare al massimo il flusso di lavoro e consentire di interrompere e riprendere facilmente una sessione di test. Inoltre, poiché il sistema è utilizzabile in qualsiasi luogo, era necessario gestire l'orientamento del tracciato e la posizione del trigger di avvio/arresto.

Gestione dell'elaborazione successiva di un batch di test e visualizzazione dei risultati aggregati

Un'altra sfida importante era l'analisi dei dati, soprattutto nel momento si doveva elaborare un batch di file di dati, selezionarne alcuni, calcolare dati aggregati, ovvero un'interpolazione di curve, visualizzare i risultati e generare un report: questo esula un po' dall'ambito di Dewesoft, ma dovevamo integrare questo processo nel flusso di lavoro di automazione dei test.

Soluzione

Qui vedremo come abbiamo affrontato il problema.

Precisione di posizionamento e sincronizzazione rispetto alla posizione del microfono senza RTK

Abbiamo deciso di utilizzare una soluzione un po' "tradizionale" ma sempre efficace per garantire un punto di attivazione preciso per l'inizio della memorizzazione: un riflettore posizionato a una distanza nota, ad esempio 15 m, dalla linea PP del microfono. Qualsiasi distanza può essere valida, purché il riflettore si trovi al di fuori dell'area di misurazione. Poiché il segnale di velocità del veicolo proveniente dal ricevitore GNSS è piuttosto preciso anche senza RTK, possiamo fare affidamento sulla distanza percorsa calcolata per ottenere la posizione del veicolo rispetto alla linea PP.

Successivamente, possiamo alzare il punto di attivazione per l'arresto della memorizzazione in base alla distanza percorsa, eventualmente tenendo conto della lunghezza del veicolo, in modo che esca completamente dall'area di misura.

Posizionando un altro riflettore sull'altro lato dell'area di misura, è possibile effettuare misure in entrambe le direzioni di marcia, avanti e indietro.

Ecco alcuni dati per verificare la precisione della distanza percorsa, calcolata a partire dalla velocità GNSS tra i riflettori a terra. La distanza nominale misurata con un metro è di 30 m; possiamo quindi presumere una precisione complessiva di circa ±2 cm nella posizione effettiva delle strisce riflettenti.

Gestione dell'automazione dei test a bordo del veicolo

L'unità di bordo misura i dati GNSS, principalmente la velocità del veicolo tramite un ricevitore GNSS a 100 Hz e il segnale di trigger "mark input" proveniente da una fotocellula che rileva il riflettore a terra.

L'unità di misura a terra si occupa della misurazione dei segnali del microfono (2 ingressi analogici campionati a 50 kHz) e dei dati della stazione meteorologica (tramite bus seriale a circa 1 Hz).

Utilizziamo un kit DS-Wi-Fi e l'opzione NTE per lo scambio di dati tra il veicolo e l'unità di misura a terra. Impostando l'unità di misura a bordo come master, un operatore sul veicolo può caricare la configurazione di misura Dewesoft e gestire l'acquisizione dei dati. In alternativa, l'unità di misura a terra può essere lasciata incustodita o utilizzata come monitor da un operatore presente sul posto.

Il setup di misura sull'unità di bordo del veicolo presenta un display che funge da interfaccia grafica "menu principale", dove alcuni pulsanti collegati ai canali di input utente consentono al sequenziatore di eseguire le funzioni richieste:

• Inizializzazione della sessione di test

• Verifica dei dati in tempo reale

• Misurazione

• Analisi

• Uscita

Quando l'utente preme un pulsante, il sequenziatore passa alla visualizzazione di misura desiderata, come verrà spiegato in seguito. Il flusso di lavoro di base è il seguente:

• Avvio della sessione di test: inserire gli ID degli pneumatici e verificare o modificare l'orientamento della pista. Il sistema necessita di queste informazioni per scambiare i segnali tra i microfoni sinistro e destro in base alla direzione di marcia.

• Verifica dei dati in tempo reale: assicurarsi che la stazione di terra stia trasmettendo i dati e che la stazione meteorologica sia funzionante.

• Avvio della misura: i seguenti passaggi vengono eseguiti in un ciclo continuo finché il conducente non decide di uscire.

• Attivazione del trigger e memorizzazione del rumore di fondo.

• Percorso attraverso la base di misura.

• Elaborazione automatica dei dati del test, conservazione o eliminazione del file.

• Analisi: In qualsiasi momento, solitamente al termine della sessione di test, l'utente può post-elaborare l'intero batch di file e generare un report, oppure eventualmente verificare ogni singola esecuzione del test.

Gestione del post-processing e del report di test

Su richiesta del cliente, siamo andati oltre DewesoftX, anche se avremmo preferito evitarlo. Il sequencer di Dewesoft, tra le altre cose, permette di richiamare un'applicazione esterna, quindi era quasi scontato pensarci. Ma quale tipo di applicazione esterna? All'epoca di questo progetto, stavamo sviluppando il nostro ambiente GarageLab, che era pronto all'uso e si è rivelato utile per il lavoro.

GarageLab è composto essenzialmente da un motore di runtime e da un wrapper che fornisce accesso a librerie di elaborazione e visualizzazione tramite codice Python: consente a un ingegnere di test o a uno specialista di applicazioni con competenze di programmazione di base di creare soluzioni automatizzate di elaborazione dati, nascondendo la complessità di attività di basso livello come il caricamento di un file di test in un determinato formato, la gestione dei canali, la creazione di una dashboard interattiva con widget accattivanti e l'esportazione dei dati. Questa semplificazione consente un'implementazione più agile e un debug sul campo degli algoritmi di elaborazione dati più efficace rispetto allo sviluppo di un'applicazione tradizionale eseguibile.

Un semplice prototipo di script di post-elaborazione ci ha permesso di verificare la fattibilità della soluzione, quindi abbiamo deciso di implementare script Python dedicati per GarageLab e di farli richiamare dal sequencer quando richiesto dal flusso di lavoro di automazione.

Implementazione

Interfaccia utente e setup di misura

Una volta delineata l'architettura, abbiamo iniziato a sviluppare un prototipo dell'Interfaccia Utente, integrando i controlli visivi nei display della configurazione di misura. Il sequencer e il setup di misura si scambiano informazioni sull'interazione dell'utente tramite canali di controllo collegati ai widget di controllo visivo nel display di misura.

In questa fase, abbiamo utilizzato un solo computer e un semplice setup di simulazione composta da alcuni canali matematici, il plugin di simulazione del veicolo e Polygon: questo ci ha permesso di simulare un veicolo che si muove avanti e indietro sul campo prove e attraversa la base di misura. Quindi, giocando in questo ambiente virtuale di base, siamo stati in grado di testare le interazioni utente e perfezionare l'interfaccia utente e la progettazione della sequenza, risparmiando molto tempo e denaro rispetto al lavoro su una vera pista di prova con un veicolo reale.

Come passo successivo, abbiamo introdotto un ambiente simulato a due PC, impostando il PC del veicolo come MU master connesso tramite Ethernet al PC a terra impostato come MU slave. Uno per l'MU del veicolo, uno per l'MU a terra, inizialmente tramite Ethernet, poi introducendo il kit Wi-Fi. In questo modo, siamo stati in grado di concentrarci sulla configurazione piuttosto che sui problemi di comunicazione Wi-Fi.

Gli script di elaborazione

Parallelamente, abbiamo perfezionato lo script Python originale per il post-processing, sviluppato in precedenza per una prova di concetto. Abbiamo adattato i calcoli e l'output visualizzato per corrispondere a una specifica dettagliata, che include controlli delle condizioni ambientali, esecuzione del test, metriche di prestazione, dati tabellari e grafici. Oltre al modulo di elaborazione, abbiamo creato uno script principale che gestisce la selezione del file di dati di test e la visualizzazione dei risultati aggregati, una tabella riassuntiva dei risultati, un grafico del rumore in funzione della velocità con adattamento di curva e l'opzione per visualizzare ogni singola esecuzione del test.

Il Sequencer ci consente di integrare lo strumento di elaborazione nella procedura di misura in modo trasparente: da un blocco "Apri file", eseguiamo il runtime di GarageLab con parametri aggiuntivi per specificare lo script da eseguire e altri input rilevanti, tra cui il percorso del file dxd pertinente.

La chiamata allo script Python di GarageLab viene effettuata dal Sequencer in diversi punti del flusso di lavoro, con parametri leggermente diversi:

• Nella procedura PassBy, automaticamente, al termine di ogni ciclo di prova, immediatamente dopo il trigger di arresto, in modo che il conducente possa verificare le condizioni di validazione e decidere se conservare o scartare il file di dati.

• Nella procedura Analyze, è accessibile ogni volta che l'utente desidera rivedere un singolo ciclo di prova o elaborare l'intero set di file di dati, esaminare i risultati, valutare l'adattamento e salvare un report in un modello personalizzato.

Assemblaggio

L'ultimo passaggio è stato quello di assemblare tutto su un'auto reale presso la nostra sede per testare il sistema in un ambiente più realistico prima della messa in servizio presso il centro prove del cliente. Collegare i sensori reali, regolare i canali matematici, impostare le condizioni di trigger appropriate e debuggare l'intero sistema richiede un paio di giorni. Anche se si è sviluppato e testato tutto, quando si va al centro prove, oltre al cliente, c'è sempre qualcosa che necessita ancora di perfezionamento o addirittura di debug.

Uno dei fattori principali è il modo in cui il cliente utilizza il sistema. Se sei tu a sviluppare il sistema, sai cosa puoi e non puoi fare, e anche se identifichi alcuni casi di utilizzo improprio, il cliente cercherà di fare qualcosa a cui non avevi pensato.

La soluzione finale

Alla fine, siamo rimasti piuttosto soddisfatti del risultato. La sequenza principale è semplice e pulita: dopo aver caricato la configurazione di misura e impostato il display principale, il sistema attende che l'utente prema uno dei pulsanti sul display di misura, quindi instrada il flusso all'attività desiderata:

• Inizializzazione dei parametri di test

• Verifica dei valori in tempo reale dai sensori

• Esecuzione della procedura di test di passaggio

• Analisi dei dati

• Uscita

Il design del menu principale è un ottimo esempio di quanto possa essere efficace la combinazione tra il Sequencer e i widget di controllo dell'input dell'utente per creare un'interfaccia intuitiva, pensata per un semplice flusso di lavoro di automazione dei test in Dewesoft.

La procedura “PassBy” è la più importante, poiché è qui che vengono eseguite le misure.

Sebbene l'avvio del salvataggio dei dati sia attivato da una fotocellula pochi metri prima che il veicolo entri nella base di misura, il conducente deve rilevare il rumore di fondo prima di iniziare ogni sessione di prova. Il conducente deve premere il pulsante per memorizzare il valore; se passa sopra la striscia riflettente prima di averlo fatto, non scatterà alcuna azione di trigger. Dopo aver premuto il pulsante, il conducente deve accelerare fino alla velocità target e guidare attraverso la base di misura.

Dopo l'arresto automatico della memorizzazione e l'uscita dalla base di misura, lo script di post-elaborazione visualizza una finestra con i risultati del test e una coppia di pulsanti per conservare o eliminare il file di test.

Il Sequenziatore attende che il conducente abbia preso una decisione, dopodiché il sistema è pronto per un'altra sessione di prova. Il ciclo continua fino al completamento del numero di sessioni di prova richieste, dopodiché il conducente torna al menu principale e seleziona Analizza per eseguire l'analisi "Globale" dell'intera sessione di prova.

Elenco apparecchiature di acquisizione dati

Hardware DAQ

Veicolo

• Tablet PC (GETAC UX10)

• DS-VGPS-HSC 

• DS-LED-DISP-VGPS 

• DS-WiFi4 

• FARETTO DI CONTROLLO (LEANE LI_LB1)

• SENSORE DI TEMPRATURA IR - OPTRIS OPT CT LT15 CF CB3

Stazione di terra

• Laptop PC 

• DEWE-43A

• 2x DSI-ACC 

• DS-GPS-SYNC-10Hz

• DS-WiFi4

• 2x GRAS-46AE - microfono

• VAISALA WXT536 - stazione meteorologica

• GRAS-42AG - calibratore per microfono

• 2x strisce riflettenti (lunghezza 0.5 m ciascuna, fissate sull'asfalto)

Software

Veicolo

• DewesoftX (2021.x o successive)

• Collegamento remoto DEWESOFT-OPT-NET

• Client Modbus DEWESOFT-PLUGIN-MODBUS- CLIENT

• Software LEANE PBN

• Runtime GarageLab GL v1.x

• Scripts python LI_PBN

Stazione di terra

• DewesoftX (2021.x o successive)

• Collegamento remoto DEWESOFT-OPT-NET

• Analisi Acustica DEWESOFT-OPT-SNDLVL

• Plugin per stazione meteorologica DEWESOFT-PLUGIN-NMEA-WS-NMEA

Misure

Non possiamo mostrare risultati numerici, ad esempio un confronto tra il sistema attuale e quello precedente, o tra pneumatici diversi. Tuttavia, possiamo descrivere come si svolge una tipica sessione di test per fornire maggiori informazioni.

Una volta arrivati ​​in pista, l'installazione dell'attrezzatura nella cabina richiede circa 30 minuti. Ciò significa posizionare il Dewe-43 e il laptop sulla scrivania, appendere i microfoni ai relativi supporti sulla base di misura, fissare le strisce riflettenti sul tracciato di prova, installare la stazione meteorologica e il modulo Wi-Fi all'esterno della cabina, collegare tutto, accendere e avviare Dewesoft.

L'allestimento del veicolo di prova richiede circa lo stesso tempo. Bisogna fissare il tablet PC sulla sua docking station in una posizione comoda, installare il display GPS, posizionare il sensore di temperatura a infrarossi rivolto verso l'asfalto e, infine, la parte più difficile su un veicolo pesante: posizionare l'antenna GNSS sul tetto e il modulo Wi-Fi nel punto più alto possibile.

Questa configurazione è essenziale per garantire una comunicazione affidabile (ovvero, un trasferimento dati quasi in tempo reale) tra l'unità di misura del veicolo e l'unità di misura a terra. Anche quando il sistema è perfettamente testato e ottimizzato, i problemi più comuni nell'utilizzo quotidiano sono legati alla connessione Wi-Fi, a causa delle crescenti interferenze delle onde radio.

Dopo la calibrazione del microfono, è possibile avviare il sequencer nell'Unità di Misura del Veicolo (master), che carica la configurazione di misura predefinita, la avvia e imposta la visualizzazione del menu principale; nel frattempo, Dewesoft NET invia la configurazione di misura all'unità di Misura a Terra (slave). Sul veicolo di prova, si accede al menu Inizializzazione per inserire gli ID delle specifiche degli pneumatici in prova e per verificare l'orientamento del tracciato di prova: Dewesoft memorizza gli ultimi valori di questi parametri, consentendo di riprendere da dove si era interrotto.

Ora è finalmente possibile iniziare.

Un set completo di misure su una singola specifica di pneumatico consiste in genere di 16 passaggi. Le prove vengono effettuate a velocità comprese tra 60 e 80 km/h (per veicoli pesanti) per ottenere una curva adeguata e interpolare i risultati alla velocità target di 70 km/h, secondo lo standard R117.

La raccolta delle 16 prove richiede dai 15 ai 20 minuti, a seconda del traffico, se la pista di prova consente la guida in entrambe le direzioni. Se la corsia PBN è a senso unico, il tempo di prova può aumentare fino a 30-35 minuti. È necessario attivare la misura a ogni prova, prestando attenzione al traffico e alla velocità di prova. Al tempo stesso, il sistema rileva automaticamente il senso di marcia, gestisce lo scambio dei dati del microfono sinistro/destro se necessario e presenta il risultato subito dopo l'arresto e la memorizzazione.

Successivamente, è necessario toccare il pulsante "Analisi globale" per ottenere i risultati complessivi della sessione. È possibile selezionare le prove con il coefficiente di correlazione migliore, rivedere le singole prove, rimuovere i valori anomali e infine salvare i dati nel report predefinito.

Poi si torna in officina dove il team di meccanici monta un altro set di pneumatici.

Al termine di una giornata di test completa, avrete testato fino a otto diverse specifiche di pneumatici, ma potreste arrivare a più del doppio se poteste cambiarli come in Formula 1!

Informazioni chiave sui test

Risulltati delle misure

In definitiva, la soluzione ha soddisfatto tutte le aspettative del cliente, dal collaudatore al responsabile dei test. Supponendo la qualità dei dati grezzi di misura  come forniti, la soluzione offre un'elevata efficienza complessiva dei test, grazie ai seguenti risultati chiave:

• Costo del sistema

• Portabilità del sistema

• Facilità d'uso

• Elaborazione automatizzata di ogni ciclo di test

• Analisi e report integrati

Tre caratteristiche distintive di questa soluzione sono significative rispetto ad altri prodotti sul mercato:

• Elaborazione dei dati e report di test completamente personalizzabili

• Un solo operatore a bordo del veicolo di prova può gestire l'intera procedura di test

• Trasmissione digitale dei dati dei microfoni, evitando ulteriori calibrazioni (i sistemi della concorrenza si basano sulla trasmissione analogica dei dati)

Conclusioni

Il punto di partenza di questo progetto è stato un elenco di apparecchiature, accuratamente selezionate in base alle esigenze del cliente e al consueto scambio di informazioni tra il nostro team Leane e il team Dewesoft. A questo punto, avevamo il sistema di misura giusto, ma dovevamo trasformarlo nella soluzione richiesta dal cliente.

Sentivamo la pressione della sfida, ma allo stesso tempo eravamo molto entusiasti perché avevamo capito come combinare i vari elementi per costruire la soluzione desiderata: l'hardware, DewesoftX, il Sequencer, GarageLab e gli script PBN. Crediamo che il risultato sia proprio come dovrebbe essere un buon progetto: semplice ed efficace.

La messa in servizio del primo sistema è avvenuta nel novembre 2021, presso un campo prove nel Nord Italia.

La soluzione è stata utilizzata regolarmente dalla primavera del 2022. Dopo oltre un anno e diverse sessioni di test presso diversi campi prove, sono stati identificati e risolti alcuni piccoli problemi in una nuova versione rilasciata alla fine del 2023, con piccole modifiche alla configurazione di Dewesoft e agli script PBN. Alla fine del 2024 abbiamo implementato nuove funzionalità per l'elaborazione dei dati e la presentazione visiva. Alla fine del 2025, il cliente ci ha chiesto di fornire un sistema gemello per la messa in servizio entro poche settimane.